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
