[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [virtio] [OASIS Issue Tracker] Created: (VIRTIO-35) race condition with multi-dword config accesses
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. > 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. > 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ł
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]