Re: Redesign of QEMU startup & initial configuration

[Mark Burton]

> On 10 Dec 2021, at 15:26, Daniel P. Berrangé <berrange@redhat.com> wrote:
> 
> On Fri, Dec 10, 2021 at 03:15:50PM +0100, Mark Burton wrote:
>> 
>> 
>>> 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?
> 
> Systemd activation doesn't really tie QEMU into systemd at
> all. The socket passing scheme is trivial and both sides are
> easily implemented by any application. It is reasonable to
> use in QEMU on any UNIX platform at least. Windows is probably
> the only complication here.
> 
>> 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.
> 
> A stable/static interface is not hard - it doesn't require all
> that much more than exposing a few APIs related to input and
> output of QAPI based JSON docs. This all exists already, you
> wwould just get skipping thue sockets serialization of QMP.
> 

Yes - good - seems we agree on that part :-)

> The biggest stumbling block for QEMU as a library is actually
> the licensing mess. Too much of our code is GPLv2-only, which
> makes it impractical to use as a library in too many use cases.
> Any app that is not GPLv2-only compatible would have to isolate
> QEMU in its own process and talk to it over RPC, at which point
> it has just reinventing QMP again.

To be clear I am not suggesting that we touch, in any way, the license. 
Stipulating that the application that uses QEMU is GPLv2 is FINE with me. All 
I’m saying is that If you want to put it in a different process - the way you 
do that (QMP or other) is then your choice.

Cheers
Mark.


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