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

[Jan Kiszka]

On 2011-11-02 19:34, Alexander Graf wrote:
> 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.

We should also be able to establish an EXPORT_SYMBOL concept, ie. only
export those functions that are supposed to be part of a component API.
Will be some work initially, but should be off long term, both to QEMU
in maintaining stable APIs and to external components in using the
proper ones.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux