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