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 1/1] ccw: add CCW_CMD_READ_STATUS


On Tue, Oct 13, 2015 at 03:27:47PM +0200, Cornelia Huck wrote:
> 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 agree for this specific change.

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

There's a range of feature bits which was supposed to be used for
transport specific features. In the end we used it for cire things
only. We can still reserve more, or CCW could gain
a "transport feature bits" command.

Anyway, this is just theoretical discussion for future protocol
extensions. Maybe they will be more like CCW_CMD_READ_STATUS,
who knows.

-- 
MST


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