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

[Alexander Graf]

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.
>   

Yes. IOW, let's go down the same road as Linux. It works well for them,
why not for us?


Alex