On Tue, Jul 19, 2022 at 04:59:22PM +0500, Drap Anton wrote: > From: "Drap, Anton" <anton.d...@auriga.com> > > There is no mechanism to load external machines and classes from modules > at the moment. This patch is to add two parameters `add_machine` and > `add_modinfo` for it. > `add_machine` is to add machines from external modules. > `add_modinfo` is to add devices from external modules, needed for a new > machine, for example. > Main aim is to have possibility to develop independent models and be able > to use it with mainline QEMU. It will help to make develop new models of > proprietary boards, simplify to use Qemu by hardware developers and extend > number of supporting boards and devices in QEMU. It will be easier for > small hardware manufacturers to use QEMU to develop their own board models > and use them to shift left of FW/SW development.
IIUC, this is suggesting QEMU load pre-built .so files created from non-upstream code, to arbitrarily extend QEMU's functionality. Such .so files will inherantly have to be GPLd as they'll derive from QEMU's internal APIs which are GPL. Given the proposed use case is to emulate non-released proprietary hardware, I struggle to see how you'll fullfill the requirements for GPL licensing of the loaded .so, without revealing your proprietary hardware design to any who receive the .so files. More generally, QEMU's existing loadable module usage is explicitly designed to try to *prevent* loading of non-upstream code. It aims to only load code that was built as part of the integrated QEMU build process. ie, QEMU's loadable module system is about making it possible to build many QEMU features, but then selectively load them at runtime to reduce footprint/attack surface. It is *not* intended to allow non-upstream code to be loaded. Aside from our goal to prevent/discourage GPL violation through closed source loadable modules, QEMU also has a strong desire to not lock ourselves into supporting a public API for loadable modules. Maintainers wish to retain flexibility to change the internal APIs at any time. Partially related to this topic, there is some work taking place with the goal of making it possible to define new machine types in QEMU from a QAPI based JSON description. The actual hardware devices and CPUs would still need code to be built into QEMU and upstream, but the way the hardware devices & CPUs are wired together would be customizable via the JSON config. That could get some, but not all, of the benefits you seek without the downsides the QEMU maintainers wish to avoid. This isn't ready to consume yet and we don't have any firm ETA either I'm afraid. With 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 :|
