Re: [virtio-dev] [PATCH] virtio-ccw: introduce revisions

[Cornelia Huck <cornelia.huck@de.ibm.com>]

On Thu, 10 Oct 2013 14:15:33 +0300
"Michael S. Tsirkin" <mst@redhat.com> wrote:

> On Thu, Oct 10, 2013 at 01:02:57PM +0200, Cornelia Huck wrote:
> > On Thu, 10 Oct 2013 11:34:30 +0300
> > "Michael S. Tsirkin" <mst@redhat.com> wrote:
> > 
> > > On Tue, Oct 08, 2013 at 05:19:05PM +0200, Cornelia Huck wrote:
> > > > Provide a new ccw that allows devices and drivers to operate on selected
> > > > revision levels.
> > > > 
> > > > VIRTIO-42
> > > > 
> > > > Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
> > > 
> > > So basically, CCW_CMD_SET_VIRTIO_REV re-implements the VIRTIO_1 feature
> > > bit in a device specific manner.
> > > Now that we have FEATURES_OK, this does not seem to be needed?
> > 
> > The idea was to implement something like a 'revision id', which we
> > didn't have for ccw. It also allows for negotiating (the driver can try
> > revisions until it finds one that the device accepts) and extra
> > configuration specifics (the currently unused data field). As it needs
> > to be done before any other channel commands, it also allows for early
> > fencing.
> 
> So does not the new initialization sequence and the new
> FEATURES_OK flag handle all that?
> I just did a commit - could you take a look please?

I don't think the features stuff would allow for extra configuration
data?

> 
> If not and we need an extra hand-shake - shouldn't it be
> generic and not transport specific?
> 

I'm trying to introduce a revision mechanism here, which pci/mmio seem
to have natively but ccw hasn't. If we'll never want to use the
exisiting revision mechanism for anything virtio specific, we can
probably ditch this. But if we do, all transports should have something
like that.