* [virtio] [PATCH v4] conformance: clarify transitional/non-transitional @ 2019-03-13 1:48 Michael S. Tsirkin 2019-03-13 11:02 ` Cornelia Huck 2019-03-13 12:08 ` Halil Pasic 0 siblings, 2 replies; 6+ messages in thread From: Michael S. Tsirkin @ 2019-03-13 1:48 UTC (permalink / raw) To: virtio, virtio-dev 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> --- Same patch was previouly sent as v2. conformance.tex | 8 ++------ 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/conformance.tex b/conformance.tex index 6df113b..8b69e39 100644 --- a/conformance.tex +++ b/conformance.tex @@ -341,13 +341,9 @@ A conformant implementation MUST be either transitional or non-transitional, see \ref{intro:Legacy Interface: Terminology}. -A non-transitional implementation conforms to this specification -if it satisfies all of the MUST or REQUIRED level requirements -defined above. - -An implementation MAY choose to implement OPTIONAL support for the +A transitional implementation MUST implement support for the legacy interface, including support for legacy drivers -or devices, by additionally conforming to all of the MUST or +or devices, by conforming to all of the MUST or REQUIRED level requirements for the legacy interface for the transitional devices and drivers. -- MST --------------------------------------------------------------------- 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 ^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [virtio] [PATCH v4] conformance: clarify transitional/non-transitional 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 1 sibling, 0 replies; 6+ messages in thread From: Cornelia Huck @ 2019-03-13 11:02 UTC (permalink / raw) To: Michael S. Tsirkin; +Cc: virtio, virtio-dev 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. That clause is added with the resolution of VIRTIO-168, no? This just clarifies things. > > VIRTIO-167 > > Signed-off-by: Michael S. Tsirkin <mst@redhat.com> > --- > > Same patch was previouly sent as v2. > > conformance.tex | 8 ++------ > 1 file changed, 2 insertions(+), 6 deletions(-) > > diff --git a/conformance.tex b/conformance.tex > index 6df113b..8b69e39 100644 > --- a/conformance.tex > +++ b/conformance.tex > @@ -341,13 +341,9 @@ A conformant implementation MUST be either transitional or > non-transitional, see \ref{intro:Legacy > Interface: Terminology}. > > -A non-transitional implementation conforms to this specification > -if it satisfies all of the MUST or REQUIRED level requirements > -defined above. > - > -An implementation MAY choose to implement OPTIONAL support for the > +A transitional implementation MUST implement support for the > legacy interface, including support for legacy drivers > -or devices, by additionally conforming to all of the MUST or > +or devices, by conforming to all of the MUST or > REQUIRED level requirements for the legacy interface > for the transitional devices and drivers. > Change looks fine. Reviewed-by: Cornelia Huck <cohuck@redhat.com> --------------------------------------------------------------------- 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [virtio] [PATCH v4] conformance: clarify transitional/non-transitional 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 1 sibling, 1 reply; 6+ messages in thread From: Halil Pasic @ 2019-03-13 12:08 UTC (permalink / raw) To: Michael S. Tsirkin; +Cc: virtio, virtio-dev 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> > --- > > Same patch was previouly sent as v2. > > conformance.tex | 8 ++------ > 1 file changed, 2 insertions(+), 6 deletions(-) > > diff --git a/conformance.tex b/conformance.tex > index 6df113b..8b69e39 100644 > --- a/conformance.tex > +++ b/conformance.tex > @@ -341,13 +341,9 @@ A conformant implementation MUST be either transitional or > non-transitional, see \ref{intro:Legacy > Interface: Terminology}. > > -A non-transitional implementation conforms to this specification > -if it satisfies all of the MUST or REQUIRED level requirements > -defined above. > - > -An implementation MAY choose to implement OPTIONAL support for the > +A transitional implementation MUST implement support for the > legacy interface, including support for legacy drivers > -or devices, by additionally conforming to all of the MUST or > +or devices, by conforming to all of the MUST or > REQUIRED level requirements for the legacy interface > for the transitional devices and drivers. > Hm, I actually liked that v3 spelled out, that legacy is not standardized (no normative exists). v4 makes things look like 'transitional' is a separate conformance profile, and that the description of the legacy interface is normative. 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 --------------------------------8<-------------------------------------- diff --git a/conformance.tex b/conformance.tex index ad7e82e..53be96e 100644 --- a/conformance.tex +++ b/conformance.tex @@ -338,22 +338,18 @@ A socket device MUST conform to the following normative statements: Transitional Driver Conformance}\label{sec:Conformance / Legacy Interface: Transitional Device and Transitional Driver Conformance} -A conformant implementation MUST be either transitional or -non-transitional, see \ref{intro:Legacy -Interface: Terminology}. - -A non-transitional implementation conforms to this specification -if it satisfies all of the MUST or REQUIRED level requirements -defined above. - -An implementation MAY choose to implement OPTIONAL support for the -legacy interface, including support for legacy drivers -or devices, by additionally conforming to all of the MUST or -REQUIRED level requirements for the legacy interface -for the transitional devices and drivers. - -The requirements for the legacy interface for transitional implementations -are located in sections named ``Legacy Interface'' listed below: + +A transitional driver or device is a conforming driver or device (as +defined by section \ref{sec:Conformance / Conformance Targets}) that aims +for interoperability with the existing body of legacy devices or drivers +(see \ref{intro:Legacy Interface: Terminology}). + +No normative specification for the legacy interface exists, but to +facilitate inter-operability with non-conforming legacy implementations, +known differences between the legacy interface and the standard interface +are documented in non-normative sections named ``Legacy Interface'' +listed below: \begin{itemize} \item Section \ref{sec:Basic Facilities of a Virtio Device / Feature Bits / Legacy Interface: A Note on Feature Bits} --------------------------------------------------------------------- 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 ^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [virtio] [PATCH v4] conformance: clarify transitional/non-transitional 2019-03-13 12:08 ` Halil Pasic @ 2019-03-14 11:06 ` Michael S. Tsirkin 2019-03-14 18:06 ` Halil Pasic 0 siblings, 1 reply; 6+ messages in thread From: Michael S. Tsirkin @ 2019-03-14 11:06 UTC (permalink / raw) To: Halil Pasic; +Cc: virtio, virtio-dev 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> > > --- > > > > Same patch was previouly sent as v2. > > > > conformance.tex | 8 ++------ > > 1 file changed, 2 insertions(+), 6 deletions(-) > > > > diff --git a/conformance.tex b/conformance.tex > > index 6df113b..8b69e39 100644 > > --- a/conformance.tex > > +++ b/conformance.tex > > @@ -341,13 +341,9 @@ A conformant implementation MUST be either transitional or > > non-transitional, see \ref{intro:Legacy > > Interface: Terminology}. > > > > -A non-transitional implementation conforms to this specification > > -if it satisfies all of the MUST or REQUIRED level requirements > > -defined above. > > - > > -An implementation MAY choose to implement OPTIONAL support for the > > +A transitional implementation MUST implement support for the > > legacy interface, including support for legacy drivers > > -or devices, by additionally conforming to all of the MUST or > > +or devices, by conforming to all of the MUST or > > REQUIRED level requirements for the legacy interface > > for the transitional devices and drivers. > > > > 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. so it's an unrelated concern - why not defer it to 1.2? - can one argue that this is a material change? we don't want to come up with these at this stage - we actually specified quite a lot about legacy interfaces. so since we did the work already, why through it away? > 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? > 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. > --------------------------------8<-------------------------------------- > diff --git a/conformance.tex b/conformance.tex > index ad7e82e..53be96e 100644 > --- a/conformance.tex > +++ b/conformance.tex > @@ -338,22 +338,18 @@ A socket device MUST conform to the following normative statements: > Transitional Driver Conformance}\label{sec:Conformance / Legacy > Interface: Transitional Device and > Transitional Driver Conformance} > -A conformant implementation MUST be either transitional or > -non-transitional, see \ref{intro:Legacy > -Interface: Terminology}. > - > -A non-transitional implementation conforms to this specification > -if it satisfies all of the MUST or REQUIRED level requirements > -defined above. > - > -An implementation MAY choose to implement OPTIONAL support for the > -legacy interface, including support for legacy drivers > -or devices, by additionally conforming to all of the MUST or > -REQUIRED level requirements for the legacy interface > -for the transitional devices and drivers. > - > -The requirements for the legacy interface for transitional implementations > -are located in sections named ``Legacy Interface'' listed below: > + > +A transitional driver or device is a conforming driver or device (as > +defined by section \ref{sec:Conformance / Conformance Targets}) that aims > +for interoperability with the existing body of legacy devices or drivers > +(see \ref{intro:Legacy Interface: Terminology}). > + > +No normative specification for the legacy interface exists, but to > +facilitate inter-operability with non-conforming legacy implementations, > +known differences between the legacy interface and the standard interface > +are documented in non-normative sections named ``Legacy Interface'' > +listed below: > \begin{itemize} > \item Section \ref{sec:Basic Facilities of a Virtio Device / > Feature Bits / Legacy Interface: A Note on Feature Bits} --------------------------------------------------------------------- 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [virtio] [PATCH v4] conformance: clarify transitional/non-transitional 2019-03-14 11:06 ` Michael S. Tsirkin @ 2019-03-14 18:06 ` Halil Pasic 2019-03-14 18:33 ` Michael S. Tsirkin 0 siblings, 1 reply; 6+ messages in thread From: Halil Pasic @ 2019-03-14 18:06 UTC (permalink / raw) To: Michael S. Tsirkin; +Cc: virtio, virtio-dev 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. 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. > - 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [virtio] [PATCH v4] conformance: clarify transitional/non-transitional 2019-03-14 18:06 ` Halil Pasic @ 2019-03-14 18:33 ` Michael S. Tsirkin 0 siblings, 0 replies; 6+ messages in thread From: Michael S. Tsirkin @ 2019-03-14 18:33 UTC (permalink / raw) To: Halil Pasic; +Cc: virtio, virtio-dev 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2019-03-14 18:33 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 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 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.