Alexander Graf <ag...@suse.de> writes: > Anthony Liguori wrote: >> On 11/02/2011 01:17 PM, Jan Kiszka wrote: >>> On 2011-11-02 18:44, Fabien Chouteau wrote: >>>> On 31/10/2011 14:12, Peter Maydell wrote: >>>>> On 29 October 2011 14:52, Alexander Graf<ag...@suse.de> wrote: >>>>>> A lot of people seem to also have code that doesn't make sense >>>>>> upstream, for example implementing a one-off device that only >>>>>> really matters for their own devboard which nobody else owns. >>>>>> For such cases, having a plugin framework would be handy. I >>>>>> interestingly enough got into the same discussion on LinuxCon >>>>>> with some QEMU downstreams. >>>>> >>>>> If we get the qdev rework done then I think we're probably in >>>>> a better position to have a plugin framework for devices. (There >>>>> are some issues about API and ABI stability guarantees, of course.) >>>>> >>>> >>>> Interesting, we have a "plug-in" implementation in our Qemu branch. It >>> >>> We have a "plugin" model here as well. It's really simple: the plugin is >>> loaded dynamically into the QEMU process and can access any global >>> function and variable. Of course, this breaks regularly. >> >> Yes, this is the Right Model. >> >> All of the work is in making the interfaces not break regularly. >> Loading a shared object is easy enough. > > I agree. In fact, we could even do it the same way as the kernel and > build all our internal hw pieces as shared objects. > > Then users who want to cut down QEMU can just remove .so files instead > of messing with the build system or code.
Shared objects have a non-zero cost, both at load time, and at run time. Whether we can accept that cost just to simplify configuration management (for a definition of "simplify") isn't obvious. If removing an optional device model from the build isn't entirely trivial, we already failed.
