[Qemu-devel] Re: qemu device emulation libraries (was [PATCH] Patches from the PyQemu project)

[Hollis Blanchard <hollisb@us.ibm.com>]

On Mon, 03 Sep 2007 15:44:13 -0500, Anthony Liguori wrote:

> On Mon, 2007-09-03 at 18:41 +0300, Blue Swirl wrote:
>> On 9/2/07, Maria Zabolotnaya <maria.zabolotnaya@gmail.com> wrote:
>> > 2-qemu-mplugin.patch
>> > Add -mplugin switch to allow loading of shared library and registering a
>> > machine declared in it.
>> 
>> Sorry to ruin your GSoC project, but the plugin system was discussed
>> last year, please see this thread:
>> http://thread.gmane.org/gmane.comp.emulators.qemu/14341/focus=14473
> 
> I've always agreed that allowing plugins was not a good idea.  However,
> I had a different thought recently.
> 
> While I don't think there's much of a reason to allow plugins for QEMU,
> it would be interesting to make some of QEMU's device emulation into
> more a of a library that could be used by other programs.
> 
> With things like KVM making it relatively simple to do CPU emulation, if
> QEMU's device emulation was available as a library (even a GPL library),
> it would be pretty easy to do interesting things without forking QEMU
> which is what everyone seems to be doing these days.
> 
> My initial thought is to make the libraries at the individual device
> level.

This could be very valuable when thinking about running qemu *on* embedded
systems with constrained memory and processing power, which is exactly what
the KVM for embedded PowerPC project is considering. In that scenario,
being able to strip out all unnecessary functionality (especially
including devices known to be irrelevant) becomes very important.

Strictly speaking, creating a library isn't required to meet that goal,
but it will enforce the modularity we need, and IMHO that is just good
coding practice.

(I'm not even talking about Anthony's points about avoiding qemu forks,
which I also agree with.)

-- 
Hollis Blanchard
IBM Linux Technology Center