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