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

[Jan Kiszka]

On 2011-11-02 19:50, Anthony Liguori wrote:
> On 11/02/2011 01:46 PM, Jan Kiszka wrote:
>> 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.
> 
> Not at first.  We don't need yet another interface that we have to try to 
> maintain.  Until things stabilize internally, the module interface should be 
> completely unstable.

For sure. It would not work out of the box anyway as way too many
functions would have to be marked - and way too much code refactored first.

We could start with a MAY_BECOME_API_SYMBOL marker that does nothing
except commenting the plan.

Jan

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