On Mon, Dec 13, 2021 at 06:30:45PM +0100, Paolo Bonzini wrote: > On 12/13/21 16:19, Markus Armbruster wrote: > > I think it's more often just three: the long one that can do everything, > > the short one that can do simple things (and doesn't tell you anything > > about the long one), and the bad one you shouldn't use. > > > > > If we're going to have a good CLI, it would ideally only have > > > one way to do each given task. > > Ideally, the long one plus good defaults suffices. > > That's hard to do, because the short one typically creates both a backend > and a frontend. It should be possible to macro-expand into the long one + a > -machine property, but that's extremely tedious work.
I don't think it has to be hard, we just need to approach the problem differently to how we've done in the past. As a general point, I think we should probably change our terminology here. IMHO using "long" and "short" options leads to the idea that they are alternatives that are both supported directly by the same binary and users switch between them depending on what they need. That's true with current QEMU impl, but I don't think we should go down that same route again, as it is not at all user friendly and leads to confusing docs due to multiple ways todo the same thing. I'd call them low-level and high-level config, to make it clearer that they're operating at different conceptual levels, and potentially (ideally even) separate binaries. I'd like a situation where machines always use low level config and humans can *always* use the high level config. This implies the high level config needs to cope with everything that the low level config can. This might sound contradictory but it is possible, if the user has ability to customize the mapping. If we assume the low-level config is the QAPI based JSON, then a high level config is essentially just a mapping of some strings into JSON. Looking at it in this light, we can then consider the high level config problem to simply be a JSON templating problem and pick an off the shelf solution for that such as Jinja. To create our so called "short option" high level API we need to be able to ship a collection of useful JSON config snippets, and have a tool which reads some CLI args using them as input variables to something like the Jinja templating engine, and then launching the low level QEMU using the template output. The benefit of using a general purpose JSON templating system in a separate binary is that we no longer have to solve everything ourselves. We can provide templates that handle some obvious common cases. If they don't do quite what a user needs, then they can just clone our template, tweak it, and carry on using the high level tool. IOW, the ability to customize the templates, means that when launching QEMU the user only ever needs to use the high level config on the CLI, and yet they still have ability to express every possible QEMU config. THis is quite a different and better experiance than today where if a short option doesn't do what you need, you have to stop using it and pick a completely different low level config instead. It also means we can ship a variety of templates with mutually exclusive defaults eg a template targetting a 1990's machine defaults, a template targetting defaults for a general purpose maximum portability VM, and a template targetting defaults for virtio. Since it would be separate from the low level QEMU, we can also decide to use a non-C language for the high level tool. eg write it in python if we want to use Jinja as templating, which would also open it up as an interesting thing for a new set of contributors who would not touch C code. 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 :|
