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
prev parent 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