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

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

[Michael S. Tsirkin]

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 

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

[Cornelia Huck]

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 

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

[Halil Pasic]

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 

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

[Michael S. Tsirkin]

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 

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

[Halil Pasic]

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 

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

[Michael S. Tsirkin]

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