OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

virtio message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [virtio] [PATCH v4] conformance: clarify transitional/non-transitional


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
> 
> [..]


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]