Re: qemu device emulation libraries (was [PATCH] Patches from the

Re: qemu device emulation libraries (was [PATCH] Patches from the

[Hollis Blanchard]

[This mail was also posted to gmane.comp.emulators.qemu.]

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-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/

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

[Hollis Blanchard]

On Tue, 2007-09-04 at 21:04 +0100, Paul Brook wrote:
> > 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.
> 
> If you care about memory overhead the last thing you want is to be loading 
> loads of bitty little shared libraries. You want to build a single binary 
> with just the features you need.

Hmm, that's a good point. Is that something you think can reasonably be
accomplished with qemu today?

-- 
Hollis Blanchard
IBM Linux Technology Center


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/

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

[Paul Brook]

On Tuesday 04 September 2007, Hollis Blanchard wrote:
> On Tue, 2007-09-04 at 21:04 +0100, Paul Brook wrote:
> > > 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.
> >
> > If you care about memory overhead the last thing you want is to be
> > loading loads of bitty little shared libraries. You want to build a
> > single binary with just the features you need.
>
> Hmm, that's a good point. Is that something you think can reasonably be
> accomplished with qemu today?

It should be fairly easy.

Paul

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/

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

[Jimi Xenidis]

On Sep 4, 2007, at 4:38 PM, Paul Brook wrote:

> On Tuesday 04 September 2007, Hollis Blanchard wrote:
>> On Tue, 2007-09-04 at 21:04 +0100, Paul Brook wrote:
>>>> 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.
>>>
>>> If you care about memory overhead the last thing you want is to be
>>> loading loads of bitty little shared libraries. You want to build a
>>> single binary with just the features you need.
>>
>> Hmm, that's a good point. Is that something you think can  
>> reasonably be
>> accomplished with qemu today?
>
> It should be fairly easy.

Why not both?
It could be like the linux kernel, =m means build an SO and =y means  
link it statically.
The key is for it to be modular and configurable.
-JX





-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/