qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Anthony Liguori
Subject: Re: [Qemu-devel] GSoC mentor summit QEMU users session
Date: Wed, 02 Nov 2011 15:42:09 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Lightning/1.0b2 Thunderbird/3.1.13

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.

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










reply via email to

[Prev in Thread] Current Thread [Next in Thread]