On Tue, 13 Oct 2015 15:54:51 +0300
"Michael S. Tsirkin" <> wrote:
> On Tue, Oct 13, 2015 at 01:44:19PM +0200, Cornelia Huck wrote:
> > On Mon, 12 Oct 2015 20:15:31 +0300
> > "Michael S. Tsirkin" <> wrote:
> >
> > > On Mon, Oct 12, 2015 at 06:53:52PM +0200, Cornelia Huck wrote:
> >
> > > > Although I'm wondering: While 2.1.2 talks about "sending" a change
> > > > notification (which one might interpret as making the interrupt
> > > > pending), 3.2.3 explicitly talks about delivering/triggering an
> > > > interrupt. Should the wording in 3.2.3 be changed to match the wording
> > > > in 2.1.2, or is this really picking at words?
> > >
> > > A bit, but sure, why not make it consistent.
> >
> > We might walk over the whole document for that. I'd give that a low
> > priority, though.
>
> BTW I hope we will use feature bits for new features in the future,
> this way they don't have to depend on each other.
> CCW_CMD_READ_STATUS is more a bugfix, so it seems sane
> to require virtio 1 for it.
I wouldn't have thought that a feature bit is appropriate for those
changes:
- A feature bit is something I'd expect the device/driver combination
to negotiate or not. There simply is no good reason to fail to
negotiate usage of this command: either both device and driver know it,
or not. [In this case, the driver might even have resorted to a "try
it, don't use again if you get a command reject".]
- I think we should avoid polluting the feature bit space with
transport-specific implementation details and reserve it for core and
device-type specific things.
