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

[BALATON Zoltan]

On Tue, 13 Oct 2020, Daniel P. Berrangé wrote:
> 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.

Discussing other compelling reasons for doubt is OK, just wanted to avoid 
having this dismissed on possible licensing problems only. I still think 
it would be a good idea to support QEMU on iOS but due to the (mostly 
security related) limitations of that platform some compromises my be 
needed. Please consider it instead of being quick to decide to avoid these 
problems by not taking the patches upstream which is a convenient solution 
from QEMU viewpoint but not helping other projects. (Other platforms may 
come up in the future with similar limitations that iOS has as more 
desktop OSes also move in the same direction to increase security so these 
may need to be handled anyway at one point, iOS is a good test case for 
that.)

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

Given that libvirt uses the command line instead of a proper API 
currently, this is not worse than that. If there was a better API or there 
will be one in the future, the shared lib API can be changed the same way 
as libvirt will need to be adapted for that but it's not reasonable to 
demand these patches to come up with that API now. So for now this seems 
to be acceptable and does not prevent cleaning it up later together with 
the planned changes you mentioned. Compatibility for the command line will 
have to be maintained until a better API is devised for use by other 
software like libvirt and anyone intending to use it as dll so this does 
not seem like added commitment.

> There is a further question about whether we want to commit to an
> architectural model where  fork() is not something we can use. A

Does Windows support fork()? I think we're already committed to support 
Windows so any solution you'll come up with will have the same problem 
anyway. So I think this does not add additional restriction that we don't 
already have either.

Regards,
BALATON Zoltan