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

[Anthony Liguori <anthony@codemonkey.ws>]

On 11/02/2011 03:24 PM, Blue Swirl wrote:
> On Wed, Nov 2, 2011 at 19:35, Anthony Liguori<anthony@codemonkey.ws>  wrote:
>> For the record, I'm opposed to ever having a stable plugin API.
>>
>> We aren't a closed source product.  If people want to have to keep up with
>> our changing internal interfaces, they can get their code merged upstream.
>
> Fully agree. I don't even think there can be any benefit for us from a
> plugin system, only API/ABI legacy maintenance effort and limitations
> to architectural changes. All benefits are external.
>
> There are other useful paths available for external users, QAPI, QMP,
> GDBstub, maybe also instrumentation in the future.
>
> Perhaps we could add a 'contrib' directory where new stuff could be
> added easily to make life outside better. It could also be used to
> clean up bitrotten devices and functionality from core. Marking things
> with deprecated attributes or something like CONFIG_EXPERIMENTAL in
> Linux could also help.

I like having dynamic modules for a few reasons:

1) It makes us start thinking in a more modular fashion.  We're getting close to 
a million lines of code--we really do need to do a better job at modularity if 
we want to keep growing at this rate.

2) It makes life a bit nicer for distributions as we grow optional dependencies. 
  Having a single QEMU binary that links against libtpms and libspice means that 
a distro needs to make libtpms/libspice a Requires in the package.  libspice has 
a ton of dependencies which makes QEMU have a ton of hard dependencies. 
Instead, if a distro can build a QEMU package and a qemu-spice package, the 
libspice dependency can be isolated to the qemu-spice package.

That means you can install QEMU on your server without pulling in all sorts of 
ffmpeg stuff if you don't care about Spice.  I'm picking on Spice here, but 
there are lots of other examples here (vde2, libbaum, SDL, etc.).

3) It lets people do out-of-tree development without forking the whole tree.  As 
much as I don't like out-of-tree development, it's a reality.  If things like 
the Android SDK could be done just as a set of plugins, it would be better for 
all of us.

4) We'll hopefully get to a point where most of what we do can be demand loaded. 
  This helps us establish a smaller in memory base which is important when it 
comes to Security Certifications[1].

[1] Security Certification has only an arguable relationship with actual 
security but it is, nonetheless, and important consideration.

Regards,

Anthony Liguori

>
>> Regards,
>>
>> Anthony Liguori
>>
>>> Alex
>>>
>>>
>>
>>
>>
>