Discussion of the implementations of VIRTIO specification
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Halil Pasic <pasic@linux.ibm.com>
Cc: virtio@lists.oasis-open.org, virtio-dev@lists.oasis-open.org
Subject: Re: [virtio] [PATCH v4] conformance: clarify transitional/non-transitional
Date: Thu, 14 Mar 2019 14:33:36 -0400	[thread overview]
Message-ID: <20190314142912-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <20190314190617.6c02225b@oc2783563651>

On Thu, Mar 14, 2019 at 07:06:17PM +0100, Halil Pasic wrote:
> On Thu, 14 Mar 2019 07:06:07 -0400
> "Michael S. Tsirkin" <mst@redhat.com> wrote:
> 
> > On Wed, Mar 13, 2019 at 01:08:36PM +0100, Halil Pasic wrote:
> > > On Tue, 12 Mar 2019 21:48:13 -0400
> > > "Michael S. Tsirkin" <mst@redhat.com> wrote:
> > > 
> > > > We already have a specification for conformance targets for
> > > > non-transitional devices.
> > > > Just add another clause that transitional devices satisfy.
> > > > 
> > > > VIRTIO-167
> > > > 
> > > > Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> > > > ---
> [..]
> > > 
> > > Hm, I actually liked that v3 spelled out, that legacy is not
> > > standardized (no normative exists).
> > 
> > Right but then I started worrying that
> > - this was not actually what the defect report said.
> >   it was basically just complaining that this chapter was not
> >   linked into any conformance targets.
> 
> I think whether legacy is a normative or a non-normative part of the
> virtio spec is what we need to decide on in the first place.

I agree it's a defect that it's unclear but I do not feel that
we need to decide this at this point in time before 1.1.




> If it is normative it needs to get linked to some conformance targets.
> If it isn't normative, it should not be a part of the conformance
> chapter.
> 
> I think the latter is closer to how we as a community see this, but I'm
> not sure.
> 
> In any case if we decide legacy is normative then we need to change "7.1
> Conformance Targets" or change the conformance statements.
> 
> Let me explain. Currently we have the conformance targets "driver"
> and "device". We would need to change this to something like
> "non-transitional driver", "transitional driver", "non-transitional
> device" and "non-transitional device" if we decide to change the targets,
> or declare that there is a variable e.g. called 'transitional' which may
> take the values 'transitional' and 'non-transitional'. But then we would
> need to convert the 'Legacy Interface' sections to 'if transitional
> has the value transitional' parts of the respective normative statements.
>
> In any case making legacy interface a normative part of the spec requires
> IMHO more work than this patch does.
> 
> 
> >   so it's an unrelated concern - why not defer it to 1.2?
> 
> I'm all for deferring VIRTIO-167.

OK before we do this let me try one more time, with
a minimally invasive change.



> > - can one argue that this is a material change?
> >   we don't want to come up with these at this stage
> 
> I would argue that making legacy interface a normative part of the spec
> is a material change.
> 
> > - we actually specified quite a lot about legacy interfaces.
> >   so since we did the work already, why through it away?
> > 
> 
> IMHO we should not throw it away. But we should make the form suit the
> intention. The intention of the conformance targets of virtio
> specification is a standard that guarantees conforming
> implementations are interoperable.
> 
> The intention behind the description of the legacy interface is not to
> standardize it, but to help people cope with the virtio stuff that
> emerged before virtio 1.0.
> 
> > > v4 makes things look like
> > > 'transitional' is a separate conformance profile, and that the
> > > description of  the legacy interface is normative.
> > 
> > 
> > I think it kind of is, isn't it?
> > 
> 
> The blurb of your v3 states the opposite:
> """
> ... legacy device descriptions are non-normative.
>   In fact virtio 0.9 is non-normative as a whole
>   and always was by design: it was early days and
>   spec evolved to document bugs in implementations.
> """
> 
> And I believe this is the truth. We certainly can make legacy interface
> normative, but then we need to take care of the formal requirements.
> 
> I see no benefit in making the legacy interface normative, because
> AFAIU we don't expect legacy implementations to get fixed if they don't
> conform to what is written in 'Legacy Interface'. AFAIU this is about
> helping people to deal with legacy, but not about claims that something
> is compliant to the legacy profile.
> 
> 
> > > I took the liberty and tweaked your v3. As stated before, I don't think
> > > transitional vs non-transitional is a big issue. I'm basically fine with
> > > anything.
> > > 
> > > Regards,
> > > Halil
> > 
> > Yea me too. For reasons above I prefer the more limited change in v4.
> > But if you prefer pls post your version separately as a patch and we
> > can have the TC choose by a ballot.
> > 
> 
> I've just sent out a modified version of it. It ain't perfect. As said
> before my preferred course of action would be:
> * defer resolving VIRTIO-167
> * figure out how do we want to resolve VIRTIO-167 by figuring out do we
> want to have a normative description of the legacy interface or not
> * figure out how to change the spec accordingly (remove legacy form
>   conformance; or add a variable or add more conformance targets that
>   cover legacy)
> 
> Cheers,
> Halil
> 
> [..]

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that 
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 


      reply	other threads:[~2019-03-14 18:33 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-13  1:48 [virtio] [PATCH v4] conformance: clarify transitional/non-transitional Michael S. Tsirkin
2019-03-13 11:02 ` Cornelia Huck
2019-03-13 12:08 ` Halil Pasic
2019-03-14 11:06   ` Michael S. Tsirkin
2019-03-14 18:06     ` Halil Pasic
2019-03-14 18:33       ` Michael S. Tsirkin [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190314142912-mutt-send-email-mst@kernel.org \
    --to=mst@redhat.com \
    --cc=pasic@linux.ibm.com \
    --cc=virtio-dev@lists.oasis-open.org \
    --cc=virtio@lists.oasis-open.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox