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

[Joelle van Dyne]

Since there seems to be some more push back on this one, I will remove
this patch from the v2 submission and submit it as a separate patch

-j

On Tue, Oct 13, 2020 at 9:40 AM BALATON Zoltan <balaton@eik.bme.hu> wrote:
>
> 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