All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.