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,
Cornelia Huck <cohuck@redhat.com>,
Stefan Hajnoczi <stefanha@redhat.com>
Subject: [virtio] Re: [virtio-dev] [PATCH v3] conformance: clarify transitional/non-transitional
Date: Tue, 12 Mar 2019 12:04:39 -0400 [thread overview]
Message-ID: <20190312114941-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <20190312160041.113d8779@oc2783563651>
On Tue, Mar 12, 2019 at 04:00:41PM +0100, Halil Pasic wrote:
> On Mon, 11 Mar 2019 12:00:46 -0400
> "Michael S. Tsirkin" <mst@redhat.com> wrote:
>
> > Clarify that:
> > - non-transitional just satisfy 3 main clauses
> > - transitional also has a legacy interface:
> > however note that it's not an optional component
> > *for transitional devices* so MAY is inappropriate
> > - 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.
> >
> > VIRTIO-167
> >
> > Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> > ---
> >
> > Changes from v1:
> > address remaining comments by Cornelia
> > Changes from v1:
> > address comments by Cornelia
> >
> > conformance.tex | 26 ++++++++++++++++++--------
> > 1 file changed, 18 insertions(+), 8 deletions(-)
> >
> > diff --git a/conformance.tex b/conformance.tex
> > index 1577c0c..c0df2a2 100644
> > --- a/conformance.tex
> > +++ b/conformance.tex
> > @@ -344,16 +344,26 @@ Interface: Terminology}.
> >
> > A non-transitional implementation conforms to this specification
> > if it satisfies all of the MUST or REQUIRED level requirements
> > -defined above.
> > +defined in section \ref{sec:Conformance / Conformance Targets} above.
>
> I think 'above' is superfluous.
>
> >
> > -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.
> > +A transitional implementation conforms to this specification
> > +if it satisfies all of the MUST or REQUIRED level requirements
> > +defined in section \ref{sec:Conformance / Conformance Targets} above
>
> I would prefer 'above' dropped, but no biggie.
>
> > +and additionally implements the legacy interface
> > +for devices and drivers, described in
> > +\hyperref[intro:Virtio PCI Draft]{[Virtio PCI Draft]}.
> >
> > -The requirements for the legacy interface for transitional implementations
> > -are located in sections named ``Legacy Interface'' listed below:
> > +\begin{note}
> > +No normative specification for the legacy interface exists,
> > +instead the ability of the device or the driver to inter-operate
> > +with the existing body of devices and drivers is a quality of
> > +implementation issue.
> > +\end{note}
>
> I don't like 'existing body of devices and drivers' because IMHO this is
> only about legacy devices and drivers. I.e. an implementation that
> conforms to this specification (or a previous version of this
> specification) is guaranteed to be inter-operable.
>
> > +
> > +To facilitate creating transitional implementations, as well as
> > +to assist in converting legacy interfaces to conforming ones,
> > +the requirements for the legacy interface for transitional implementations
> > +are located in non-normative sections named ``Legacy Interface'' listed below:
>
> I have a hard time to tell if this change makes transitional vs
> non-transitional clearer or not.
>
> I think there is a dissonance between 'no normative specification for
> the legacy interface exists' and 'transitional implementation conforms
> to this specification if ...'.
>
> The latter suggests that based on this specification and the referenced
> draft together do provide, what is necessary to decide if a given
> implementation is a transitional implementation that conforms to this
> specification.
>
> The former suggests that only the non-transitional, i.e. virtio
> conforming, part of the transitional device is actually well specified.
> Please note that the non-normative sections do contain constructs that
> are normally reserved for normative statements (e.g. MUST).
> AFAIU a transitional implementation is any implementation that is
> conforming to this specification and aims to provide some
> inter-operability with some legacy implementations that do not conform
> this specification. A non-transitional implementation is an
> implementation that is conforms to this specification and does not care
> about inter-operability with implementation that don not conform to this
> specification.
>
> I think people familiar with virtio already have a good understanding of
> transitional and non-transitional. Because of this I'm going to abstain
> on this.
>
> Regards,
> Halil
OK I'm convinced, I've send v2 which is a much smaller change.
Pls review that before I start another ballot.
--
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
next prev parent reply other threads:[~2019-03-12 16:04 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-11 16:00 [virtio] [PATCH v3] conformance: clarify transitional/non-transitional Michael S. Tsirkin
2019-03-11 16:49 ` Cornelia Huck
2019-03-12 15:00 ` [virtio] Re: [virtio-dev] " Halil Pasic
2019-03-12 16:04 ` Michael S. Tsirkin [this message]
2019-03-12 16:35 ` Halil Pasic
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=20190312114941-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=cohuck@redhat.com \
--cc=pasic@linux.ibm.com \
--cc=stefanha@redhat.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.