Re: Redesign of QEMU startup & initial configuration

[Daniel P . Berrangé]

On Tue, Dec 14, 2021 at 02:11:11PM +0100, Mark Burton wrote:
> 
> 
> > On 14 Dec 2021, at 14:05, Daniel P. Berrangé <berrange@redhat.com> wrote:
> > 
> > On Mon, Dec 13, 2021 at 09:22:14PM +0100, Mark Burton wrote:
> >> 
> >> 
> >>> On 13 Dec 2021, at 18:59, Daniel P. Berrangé <berrange@redhat.com> wrote:
> >>> 
> >>> …. we no longer have to solve everything
> >>> Ourselves. 
> >> 
> >> I support this sentiment.
> >> 
> >> Lets re-factor the code so people can build what they need using an API.
> >> Actually, ‘QEMU’ only need support the existing CLI, and provide a 
> >> suitable internal API.
> >> If that API was relatively stable, that would help those (few) who 
> >> maintain a different startup mechanism (but its only a ’nice to have’). 
> >> (Making that convenient, as Paolo has show, would also be ’nice to have’).
> > 
> > To be clear I do strongly believe that the QEMU project needs
> > to deliver the higher level simplified interface too. I just
> > want that higher level interface to be flexible enough to
> > let end users expand on what it offers, without having to
> > write C code nor having to switch entirely to the low level
> > interface like we do today.
> > 
> > IOW, QEMU needs to deliver more than just a low level building
> > block API.
> 
> Why?
> Clearly it would be nice if “higher level” interfaceS existed in
> the world. Clearly QEMU could provide one, two, or many. But, why
> do you think QEMU ‘must’ provide them?

To serve our users who are not all wanting to be use a management
layer. They want to be using a simple binary to spin up adhoc
VMs. This is the reason why we've kept most of the short option
CLI args in the existing QEMU binaries, despite having more
comprehensive low level replacement args. 

If we just declare we're not going to provide this simple binary
any more, then we're just casting these users adrift. This in
effect means they'll just carry on existing the historical QEMU
binaries and we'll never be able to eliminate them, so we'll be
maintaining two things forever.

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 :|