On Mon, Nov 19, 2018 at 07:47:40PM -0200, Eduardo Habkost wrote: > On Mon, Nov 19, 2018 at 01:07:59PM -0500, Michael S. Tsirkin wrote: > n > > On Mon, Nov 19, 2018 at 11:41:05AM +0100, Cornelia Huck wrote: > > > On Fri, 16 Nov 2018 01:45:51 -0200 > > > Eduardo Habkost <ehabkost@xxxxxxxxxx> wrote: > > > > > > > On Thu, Nov 15, 2018 at 05:29:24PM +0100, Andrea Bolognani wrote: > > > > > > > > One thing that I'm very much not convinced about is the naming, > > > > > specifically leaving the virtio revision out: I get it that we > > > > > Should Never Need™ another major version of the spec, but I'm > > > > > afraid discounting the possibility outright might prove to be > > > > > shortsighted and come back to bite us later, so I'd much rather > > > > > keep it. > > > > That's not the claim. In fact the reverse is true - a major revision can > > come at any point. The claim is that virtio compatibility is not based > > on version numbers. And another claim is that you can trust the > > virtio TC not to overload terminology that it put in the spec. So use > > that and you should be fine. Come up with your own and end up writing > > another spec just to document it. > > > > > > > > > > > > And once that's done, "non-transitional" (while matching the > > > > > language of the spec) starts to look a bit unnecessary when you > > > > > could simply have > > > > > > > > > > virtio-*-pci > > > > > virtio-*-pci-1 > > > > > virtio-*-pci-1-transitional > > > > > > > > > > instead. But I don't feel as strongly about this as I do about > > > > > keeping the virtio revision in the device name :) > > > > > > > > I like that suggestion. Makes the device names more explicit > > > > _and_ shorter. I'll do that in v3. > > > > > > OTOH, that would mean we'd need to introduce new device types if we > > > ever start to support a virtio 2.x standard. My understanding was that > > > we'll want separate device types for transitional and non-transitional > > > for two reasons: the bus which a device can be plugged into, and > > > changing ids. Do we really expect huge changes in a possible 2.x > > > standard that affect virtio-pci only, and not other virtio transports > > > as well? > > > > Yes I think adding a version there is a mistake. > > transitional/legacy/non-transitional are spec terms so > > they are unlikely to change abruptly. OTOH virtio TC can > > just decide next version is 2.0 on a drop of a hat. > > > > And I strongly believe command line users really really do not want all > > this mess. Even adding "pci" is the name confuses people (what are the > > other options?). For command line model=virtio is pretty much perfect. > > So all these names are there primarily for libvirt's benefit. > > And the only input from libvirt devs so far > > has been that it's unclear how does cross version > > migration work. That needs to be addressed in some way. > > What still needs to be addressed? I don't belive you answered Daniel's question. > Just keep the existing device > types on migration. We could make additional promises about > compatibility with the disable-modern and disable-legacy > properties, but I don't see why we need to do it unless we start > deprecating the old device types. Then the answer seems to be in the negative? > > > > > So can we maybe start with a libvirt domain xml patch, with an > > implementation for existing QEMU, get that acked, and then just map it > > back to qemu command line as directly as possible? > > I don't know what you mean here by "libvirt domain XML patch". > > Do you mean solving the problems only on the libvirt side, > keeping the existing device types? Why would we do that? It > would be a hack making the situation even messier. > > If libvirt needs us to provide better interfaces, let's cooperate > with them. I'd like us to avoid having yet another "the problem > must be solved in the other layer first" deadlock here. I mean IIUC libvirt is the solve user that will benefit from this patch. Let's at least get an ack confirming it does make their lives easier. > -- > Eduardo -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
