Re: [Qemu-devel] GSoC mentor summit QEMU users session

[Markus Armbruster]

Alexander Graf <address@hidden> 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<address@hidden>  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.