[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [virtio] [PATCH 1/1] ccw: add CCW_CMD_READ_STATUS
On Tue, 13 Oct 2015 15:54:51 +0300 "Michael S. Tsirkin" <mst@redhat.com> 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" <mst@redhat.com> 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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]