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