[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: BALATON Zoltan
Subject: Re: [PATCH 04/10] meson: option to build as shared library
Date: Tue, 13 Oct 2020 18:40:03 +0200 (CEST)

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]