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. 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. There is a further question about whether we want to commit to an architectural model where fork() is not something we can use. A significant area of development for QEMU right now is around the modularization of the device model such that QEMU is no longer a single process, but rather a collection of processes, each proc responsible for some specific hardware emulation. Thus far all the device modularization stuff is strictly optional, but we have the freedom to make it mandatory and use it transparently behind the scenes. If we declare this shared library model supported in order to avoid use of fork, then we're restricting our future options wrt device modularization. So including the license issue, that's three major questionmarks around desirability of supporting use of QEMU as a shared library. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
