[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [virtio] [PATCH v10 01/10] virtio: document forward compatibility guarantees
On Wed, Mar 08, 2023 at 03:16:41PM +0100, Cornelia Huck wrote: > On Tue, Mar 07 2023, David Edmondson <david.edmondson@oracle.com> wrote: > > > "Michael S. Tsirkin" <mst@redhat.com> writes: > > > >> On Mon, Mar 06, 2023 at 01:53:50PM +0000, David Edmondson wrote: > >>> "Michael S. Tsirkin" <mst@redhat.com> writes: > >>> > >>> > Feature negotiation forms the basis of forward compatibility > >>> > guarantees of virtio but has never been properly documented. > >>> > Do it now. > >>> > > >>> > Suggested-by: Halil Pasic <pasic@linux.ibm.com> > >>> > Signed-off-by: Michael S. Tsirkin <mst@redhat.com> > >>> > --- > >>> > content.tex | 42 ++++++++++++++++++++++++++++++++++++++++++ > >>> > 1 file changed, 42 insertions(+) > >>> > > >>> > diff --git a/content.tex b/content.tex > >>> > index 0e474dd..0c2d917 100644 > >>> > --- a/content.tex > >>> > +++ b/content.tex > >>> > @@ -114,21 +114,63 @@ \section{Feature Bits}\label{sec:Basic Facilities of a Virtio Device / Feature B > >>> > In particular, new fields in the device configuration space are > >>> > indicated by offering a new feature bit. > >>> > > >>> > +To keep the feature negotiation mechanism extensible, it is important > >>> > +that devices \em{do not} offer any feature bits that they would not be > >>> > +able to handle if the driver accepted them (even though drivers are not > >>> > +supposed to accept them in the first place even if offered, according to > >>> > +this version of the specification.) > >>> > >>> I find this (the bit in parenthesis) confusing. > >>> > >>> Why are drivers not supposed to accept features that they have been > >>> offered, given that they can't know that the device cannot handle the > >>> feature that it just offered? > >>> > >>> Is this alluding to the later section: > >>> > >>> > feature bits not described in this specification, reserved feature > >>> > bits and feature bits reserved or not supported for the specific > >>> > transport or the specific device type > >>> > >>> ? > >> > >> exactly. how would you put this better? given an example? > > > > Perhaps it would be enough to say: > > > >> (even though drivers are not supposed to accept unrecognised features in > >> the first place even if offered, according to the specification) > > > > "Unrecognised" is intended as a shorthand for the whole "not described, > > reserved, ...". Maybe "unrecognised or reserved"? > > Hm, what about > > "even though drivers are not supposed to accept any unspecified, > reserved, or unsupported features even if offered..." > > ? ok > I'm not sure how we can make this both short and descriptive enough...
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]