Re: Redesign of QEMU startup & initial configuration

[Mark Burton]

> On 10 Dec 2021, at 12:25, Daniel P. Berrangé <berrange@redhat.com> wrote:
> 
> On Fri, Dec 10, 2021 at 09:34:41AM +0100, Paolo Bonzini wrote:
>> On 12/9/21 20:11, Daniel P. Berrangé wrote:
>>>>    They still need to bootstrap a QMP monitor, and for that, CLI is fine
>>>>    as long as it's simple and stable.
>> 
>> I would go a step further and say that the QMP monitor socket should be
>> created by whoever invoked QEMU and passed down via systemd's socket
>> activation protocol, with a fallback to stdin/stdout.

Could we take one more small step …. 
(Sorry - I’m sure you’ll all hate me for pointing at the elephant in the room….)

Why should QEMU itself handle this? You may want to use systemd socket 
activation, I may be happier with a different approach. The commonality is 
surely at the level of the underlying QAPI.
Being able to build QEMU as a ….. library, with a single entry point to access 
the QAPI would allow the QEMU community to focus on it’s key ‘kernel’, while 
others are able to propose integrated solutions like activation through systemd 
an/or whatever libvirt does etc etc…. By all means there can be a systemd-qemu 
project…. But does that have to be baked into QEMU?
I know there’s a history on the use of the “Library” word - equally there is a 
notion of a library needing a static interface etc - I propose we agree upon a 
single access mechanism to the QAPI - who’s existence and stability we have 
already (I think) agreed upon.

This requires a ‘full’ QAPI, of course, and a bit of care in the build system. 
It allows total flexibility, and the guarantees of stability reach no further 
than what we're proposing anyway. The existing CLI can migrate (fast or slow) 
to using QAPI….

Cheers
Mark.


> 
> That's an interesting idea, firmly relegating any "human friendly"
> targetted CLI to a separate program, that in turn invokes this
> low level QEMU binary. I do like the simplicity of this and the
> strict division of the layers it provides us, as it will help keep
> us honest when designing human friendly interfaces.
> 
> To be clear, I do think the QEMU project should be delivering a
> nice simple human targetted interface, and ideally using the
> '/usr/bin/qemu' binary name, and able to deliver users a machines
> with a modern hardware config that can evolve over time.
> 
>>>> = Appendix: Why further incremental change feels impractical =
>>>> 
>>>> Crafting a big change in small steps sounds great.  It isn't when we
>>>> have to make things worse before they can get better, and every step is
>>>> painfully slow because it's just too hard, and the end state we aim for
>>>> isn't really what we want.
>>> 
>>> I can't disagree with this. If we carry on trying to evolve vl.c
>>> incrementally we are doomed to be stuck with a horrible starstup
>>> process for enternity (or at least as long as I'll still be
>>> working as QEMU maintainer).
>> 
>> ... and if you compare vl.c in 5.2 and now, and consider current vl.c to be
>> horrible, my knowedge of English does not include an adjective to describe
>> the 5.2 state.  Some incremental work _is_ possible or even necessary, and
>> has been done already.
> 
> Right, I'm not saying vl.c hasn't improved, but we're never going
> to get out of the peculiar historical startup ordering rules we
> have today by incremental fixes, without breaking people.
> 
> 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 :|
>