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 v10 01/10] virtio: document forward compatibility guarantees


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..."

?

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]