On Tue, Oct 08, 2013 at 06:38:12PM +0100, Pawel Moll wrote:
> On Tue, 2013-10-08 at 14:38 +0100, Michael S. Tsirkin wrote:
> > Well basically what I am saying is that spec should say that drivers
> > MUST support both revision 1 and revision 2
>
> No, changing the version number just for the sake of changing it makes
> no sense whatsoever.
It's for the sake of making sure old drivers don't bind
to non transitional devices.
> > MUST always look at the
> > VIRTIO_1 feature bit to check whether device supports the new interface
> > (as opposed to checking the revision).
>
> The version register has one intention - make the changes of the control
> registers layout (except for the first two of them :-) easy. Sounds like
> this is where we are. No if, buts or guessing - different register
> layout, different version. So that's the transport.
>
> The feature bit is still required for the functional drivers (block,
> net, scsi etc). Unless I don't understand the idea :-)
>
> It seems that it would be possible to have a legacy functional device
> with new MMIO control register layout. I'm not sure this would be
> useful, but it should be possible.
I'm sorry I don't understand. We have a set of terms
defined in the spec now- transitional non transitinal legacy.
Can we frame discussion in these terms please?
Changing version makes it a non transitional device.
I am asking for ability to make transitinal
devices as well, this means that
- devices must have ability to have version 1
- drivers must not use version to detect legacy interface
> > This removes info duplication between revision and feature bit
> > and will allow transitional devices if we ever want them
> > after all, without adding complexity.
>
> Implementation of the transitional devices *will* be more complex than
> ones following one *or* the other version of the spec, I think you can't
> argue that.
>
> I sympathize with your effort of making the PCI (server) devices/drivers
> backward compatible. But also very *very* strong doubts whether the same
> makes sense in the MMIO world (let's call it "embedded"). I'll make the
> Linux driver work with both kinds of the devices. Other OSes? Don't care
> - I'm 99.9% sure that there are no non-Linux MMIO drivers. Running old
> kernel (legacy driver only) on cutting edge model with new device?
> Tough, I don't think I care either - upgrade the kernel.
>
> > Is this acceptable to you?
>
> My acceptance doesn't really matter here - I can be simply voted
> wrong :-) I'm just trying to maintain the MMIO transport's modus
> operandi - keep it simple.
>
> Anyway, I'll think more about it. Feel free to point out holes in my
> reasoning ;-)
>
> Paweł
>
