On Mon, Dec 13, 2021 at 06:37:44PM +0100, Paolo Bonzini wrote:
> On 12/13/21 16:28, Markus Armbruster wrote:
> > Would you object to me expanding the CLI here to the point where I think
> > we can deprecate the old binary?
> >
> > If yes, why?
>
> Yes, for two reasons.
>
> First, because there will be usually differences between the command lines
> as mentioned elsewhere in the thread. qemu-system-* is a good name, but one
> that is already taken by 15 years of docs using the existing command line.
T
Lets pick naming to make it clearer who/what each binary is targetted
towards. e.g.
- /usr/bin/qemu-buildvm-$TARGET for the low level binary that just
speaks QMP on stdio / passed in pre-opened socket, targetted
at mgmt apps and needs a series of commands to build a VM up
from scratch
- /usr/bin/qemu (or /usr/bin/qemu-vm) - for a high level binary that
targets humans and uses a templating system to expose a friendly
simple config, that internally invokes whichever target specific
/usr/bin/qemu-buildvm-$TARGET is implied, plus any other vhost-user
backends, or whatever other helper processes it needs
> Second, because a command line is really hard to get right as complexity
> increases. QMP is the way to go to get as clean as possible a configuration
> mechanism. There *will* be a second set of warts layered on top of the
> above code, and I don't want that.
Turning the high level / short config into a general purpose templating
problem, strictly separated from the low level binary using QMP, means
gives us a more flexible way to live with the warts IMHO.
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 :|
