On Wed, Jan 16, 2019 at 03:07:07PM +0100, Andrea Bolognani wrote: > On Wed, 2019-01-16 at 11:13 +0000, Daniel P. Berrangé wrote: > > On Wed, Jan 16, 2019 at 12:01:00PM +0100, Andrea Bolognani wrote: > > > Based on what I can recall from my own, more recent, attempt at > > > fixing the mess, the main blocker was that in order to keep > > > accepting all existing configurations you'd basically have to > > > still store the model as a string and only at a later time > > > convert it to an enum. > > > > The enum should cover all existing reasonably expected configs. Sure I > > imagine we might miss a few, especially for obscure architectures or > > hypervisors, but that would just be bugs to be fixed > > Until we've fixed said bugs, guests using such models would just > disappear though, wouldn't they? That doesn't sound acceptable. We could do a multi-step conversion. First define an enum and report all known enum values in the domain capabilities. Taint any guest using a nic with doesn't match. A year or so later, then finally enforce the enum usage. > And defining even the incomplete enum would require someone to > be familiar with all drivers in order to know which models are > commonly used, or at all available. It isn't as bad as it seems. VMWare has whitelisted names, Hyperv doesn't report models at all, Xen is a small finite set. QEMU is the only hard one given the huge set of system emulators. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
