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

[Markus Armbruster]

Anthony Liguori <address@hidden> writes:

> On 11/02/2011 03:24 PM, Blue Swirl wrote:
>> On Wed, Nov 2, 2011 at 19:35, Anthony Liguori<address@hidden>  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.

You can turn any collection of .o and .h into .so with the same .h.
Can't see how that will magically make us think in a more modular
fashion.

But once you have clear interfaces, linking modules separately can help
controlling the cross-module references, and thus help defeating
attempts to bypass the interfaces.

Let's start with step 1.  Earth to Anthony, earth to Anthony, please get
the QOM job done before chasing dynamic modules!  ;-P

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

If history is any guide, Google forks everything anyway ;)

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