Avi Kivity wrote:
> Anthony Liguori wrote:
>> Plugins are not the solution though.
> 
> What about non-plugin dlopen()?  Right now building qemu (with all
> options enabled) requires a large amount of libraries, hence a lot of
> dependencies.  For example, a server setup that will only be used with
> -vnc needs to have SDL installed.  This will only get worse with opengl
> support.
> 
> I'm thinking of something similar to linux kernel modules: no backward
> compatible ABI, simply load-on-demand functionality that can be packaged
> separately to reduce dependencies.  With kvm integrated, we could even
> make the cpu emulator an optional loadable module.

At work, we are currently using this model to separate a very special
machine emulation from the latest and greatest qemu (or kvm-userspace)
core. We only patch the core with support to load "machine libraries"
that provide additional QEMUMachine definitions. The idea is definitely
_not_ to distribute a binary-only machine library with the product one
day, but to ease the build process. We also face the unavoidable API
breakages from time to time, and the whole things is not really clean
due to callbacks into the core all over the place, but otherwise it does
its job.

As it is not clean and we are still busy with more important stuff, I
haven't posted any RFC yet. The biggest issue, besides finding a
consensus if such pluging concepts are desired at all, is working out
clean (but not necessarily stable) APIs for calling from the plugins
into the core. Right now we simply export everything.

Jan