Hi Guys,
Let me clarify my position about out of tree devices. Yes, I understand that current QEMU politics is to have all the supported platforms inside QEMU source tree, but actually simulator core development, development of the devices standard library and development of virtual platforms are three different tasks. Moreover different people interested in different parts of QEMU. QEMU core developers not interested in supporting and maintaining tons of platforms available on the market. Virtual platform developers not interested and usually don’t have resources to merge their changes upstream. So we have a lots of abandoned QEMU forks for different platforms. For example we’re now working on Raspberry Pi 4b implementation for our internal needs and we’re planning to merge it upstream. It’s based on some QEMU fork author of which wasn’t able to complete it and commit upstream. And it can’t be used with later QEMU without some efforts to port it to newer QEMU version. Nobody supports and maintaining it since constant efforts necessary to be in sync with QEMU mainline. So my opinion is that core development, core device library and virtual platform development should be divided to make life easier for everybody. And this changes is first step to it. About legal reasons and GPL violations. Possibility to make .so with machine separately and load it without providing sources is a legal risk and can’t be completely solved with technical actions. Ban on external modules just makes it more difficult for everybody to use not upstream code (including GPL violators, but not only for them) and doesn’t block ability to distribute full QEMU fork with closed models without providing sources. So I don’t see any reason to make technical limitations which actually can’t solve legal problem. Best Regards, Anton Software engineer from Auriga LLC<http://www.auriga.com/> ________________________________ От: Daniel P. Berrangé <berra...@redhat.com> Отправлено: 19 июля 2022 г. 19:25 Кому: Drap Anton Копия: qemu-devel@nongnu.org; Drap, Anton Тема: Re: [PATCH v2] Loading new machines and devices from external modules 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 :| libvirt: The virtualization API<https://libvirt.org/> libvirt.org libvirt, virtualization, virtualization API |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
