Re: [PATCH 04/10] meson: option to build as shared library

["Daniel P. Berrangé" <berrange@redhat.com>]

On Tue, Oct 13, 2020 at 08:16:46AM -0700, Joelle van Dyne wrote:
> I will start a separate conversation of UTM's license compatibility.
> 
> Regarding the patch, would some sort of warning message in configure
> (if building as a shared library) regarding the license be wise? Or
> would it pollute the output logs?

I think there's also a more fundamental question of whether this is
a concept we actually want to support at all.

IIUC, this shared library just exposes a "qemu_main" method which
the external app has to jump into. IOW, the "char **argv" parameter
to qemu_main becomes the ELF library ABI.  Declaring this a shared
library interface is a non-negligible commitment for QEMU maintainers,
especially given that there is alot about QMEU's command line parsing
that maintainers do not like and wish to change.

There is a further question about whether we want to commit to an
architectural model where  fork() is not something we can use. A
significant area of development for QEMU right now is around the
modularization of the device model such that QEMU is no longer a
single process, but rather a collection of processes, each proc
responsible for some specific hardware emulation. Thus far all the
device modularization stuff is strictly optional, but we have the
freedom to make it mandatory and use it transparently behind the
scenes. If we declare this shared library model supported in order
to avoid use of fork, then we're restricting our future options
wrt device modularization.

So including the license issue, that's three major questionmarks
around desirability of supporting use of QEMU as a shared library.


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