On Tue, Jan 07, 2020 at 01:23:18PM +0100, Paolo Bonzini wrote:
> On 07/01/20 13:18, Thomas Huth wrote:
> > I don't think we need a separate priority parameter here. But IMHO it's
> > really rather common practice to prioritize the last option. So while
> > it might be more "self-explanatory" to a CLI newbie if the first
> > occurrence got the highest priority, it might be rather confusing
> > instead for a CLI veteran...?
>
> Prioritising the last certainly makes sense for a choose-one-only
> option, but I'm not sure it's the same for a choose-best option. After
> all it was -machine accel=kvm:tcg, not -machine accel=tcg:kvm...
IIUC, the main use case for specifying multiple accelerators is
so that lazy invokations can ask for a hardware virt, but then get
fallback to TCG if not available. For things that should be platform
portabile, there's more than just kvm to consider though, as we have
many accelerators. Listing all possible accelerators is kind of
crazy though no matter what the syntax is.
How about taking a completely different approach, inspired by the
-cpu arg and implement:
-machine accel=best
which will just "do the right thing(tm)", picking the best available
option for the current host.
Then declare the use of mulitple -machine args is unsupported
or undefined semantics, and ignore this priority question entirely
thus avoid making QEMU's CLI even more complex than it already is
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 :|
