Re: [Qemu-devel] [PATCH] Patches from PyQemu project

[Paul Sokolovsky <pmiscml@gmail.com>]

Hello Anthony,

Monday, September 3, 2007, 11:44:13 PM, you 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


   As Maria's GSoC mentor for the project, I'm glad to add the following
comments:

> I've always agreed that allowing plugins was not a good idea.  However,
> I had a different thought recently.

  Great! Some believed this is bound to happen sooner or later.

> While I don't think there's much of a reason to allow plugins for QEMU,

  Oh, come on! ;-)

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

  You noticed that too? Back in that 2006 thread, this was given as one
(among many) of reasons why plugins are usuful. Back then I gave one
example of fork in the domain of my interest (ARM-based real-world
products): gumstix emulation. Now in the same area I know about
the following forks: gumstix, Neo1973 (OpenMoko), hackndev.com fork for
Palm machines emulation, now this recently announced Nokia770/800
effort. Possibly, good enough count already to think what's good for
qemu and what's not.

> My initial thought is to make the libraries at the individual device
> level.

  Roundabout way works too, why not. I can understand your idea to
ignore end users' needs and instead treat QEMU as "research" platform.
Well, after all our project was structured exactly this way - instead of
crafting patches which won't be accepted upstream anyway, it was
decided to treat the whole QEMU as a library and control it using
high-level language. That plugin-support patch was produced as a proof
of concept on the initial project stage, just to show how it is easy
(well, who'd think otherwise).

  Of course, you, as a primary QEMU contributor could do it
differently, but indeed, why make users' life easier than they worth?
Let's offload functionality of loading all those "libraries at the
individual device level" (which are not plugins at all btw) to some
3rd-party "launcher". After all, we can prophet that again, sooner or
later that functionality still will become part of QEMU, right?

> Regards,

> Anthony Liguori

>> > 4-qemu-no-statics.patch
>> > Remove static declaration from some QEMU symbols, so they were exported from shared
>> > library.
>> 
>> I don't think this API is worth supporting in the future.
>> 
>> 





-- 
Best regards,
 Paul                            mailto:pmiscml@gmail.com