OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [PATCH v8 1/9] virtio: document forward compatibility guarantees


On Wed, Nov 23, 2022 at 10:21:52AM +0100, Cornelia Huck wrote:
> On Tue, Nov 22 2022, "Michael S. Tsirkin" <mst@redhat.com> wrote:
> 
> > On Mon, Nov 21, 2022 at 04:24:26PM +0100, Cornelia Huck wrote:
> >> On Sun, Nov 20 2022, "Michael S. Tsirkin" <mst@redhat.com> wrote:
> >> >  \drivernormative{\subsection}{Feature Bits}{Basic Facilities of a Virtio Device / Feature Bits}
> >> >  The driver MUST NOT accept a feature which the device did not offer,
> >> >  and MUST NOT accept a feature which requires another feature which was
> >> >  not accepted.
> >> >  
> >> > +The driver MUST validate the feature bits offered by the device.
> >> > +The driver MUST ignore and MUST NOT accept 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.
> >> 
> >> I think we can mandate that the driver MUST NOT accept these feature
> >> bits; but can we mandate that it MUST ignore them? Alternatively, it
> >> could also set the FAILED status bit.
> >
> > Well if drivers assume there are no
> > new features then we can't add new ones and forward compatibility
> > breaks. We always assumed drivers ignore features they don't
> > understand.  This is why I propose mandating this strongly and
> > I feel it's okay to add such a requirement even at this late stage
> > anything violating this would have been broken many times already.
> > No?
> 
> Hm, right. Let's keep this as MUST.
> 
> >
> >> Also, what does "specific device type" mean in this case? Does it refer
> >> to a driver that supports devices virtio-foo, virtio-bar, and
> >> virtio-baz, and so needs to ignore a feature that is only valid for
> >> virtio-foo, but not for virtio-bar or virtio-baz, if it is offered for
> >> anything that is not virtio-foo?
> >
> > For example, virtio-rng has no features, driver must ignore
> > all device specific feature bits and only negotiate generic
> > and transport specific feature bits.
> 
> Isn't that the same as a feature bit that the driver does not know?
> Feature bit 0 means different things for different device types, and for
> virtio-rng, it's simply an undefined feature (as of now).
> 
> > How would you put it better?
> 
> Let me try:
> 
> The driver MUST ignore and MUST NOT accept any feature bit that is
> \begin{itemize}
> \item not described in this specification,
> \item marked as reserved,
> \item not supported for the specific transport,
> \item not defined for the device type.
> \end{itemize}

ok, thanks!



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]