On Mon, Nov 28, 2011 at 11:25:43AM +1030, Rusty Russell wrote: > > > But I'm *terrified* of making the spec more complex; > > > > All you do is move stuff around. Why do you think it simplifies the spec > > so much? > > No, but it reduces the yuk factor. Which has been important to adoption. Sorry if I'm dense. Could you please clarify: do you think we can live with the slightly higher yuk factor assuming the spec moves the legacy mode into an appendix as you explain below and driver has a single 'legacy' switch? > And that's *not* all I do: reducing the number of options definitely > simplifies the spec. For example, the spec should currently say > (looking at your implementation): > > Notifying the device > ==================== > If you find a valid VIRTIO_PCI_CAP_NOTIFY_CFG capability, and you can > map 2 bytes within it, those two bytes should be used to notify the > device of new descriptors in its virtqueues, by writing the index of the > virtqueue to that mapping. > > If the capability is missing or malformed or you cannot map it, the > virtqueue index should be written to the VIRTIO_PCI_QUEUE_NOTIFY offset > of the legacy bar. > > Vs: > > Notifying the device > ==================== > The index of the virtqueue containing new descriptors should be written > to the location specified by the VIRTIO_PCI_CAP_NOTIFY_CFG capability. > (Unless the device is in legacy mode, see Appendix Y: Legacy Mode). Yes, I agree, this is better. ... > Look, I try to be more inclusive and polite than Linus, but at some > point more verbiage is wasted. > We will have single Legacy Mode switch. Sorry, I'm adding more verbiage :( When you say a single Legacy Mode switch, you mean that the driver will assume either legacy layout or the new one, correct? > Accept it, or fork the standard. > > If you want to reuse the same structure, we're going to need to figure > out how to specify the virtqueue address without a fixed alignment, and > how to specify the alignment itself. I think I see a way to do that in a relatively painless way. Do you prefer seeing driver patches or spec? Or are you not interested in reusing the same structure at all? -- MST _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
