qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Question about qemu firmware configuration (fw_cfg) dev


From: Gleb Natapov
Subject: Re: [Qemu-devel] Question about qemu firmware configuration (fw_cfg) device
Date: Mon, 19 Jul 2010 10:55:33 +0300

On Mon, Jul 19, 2010 at 08:44:16AM +0100, Richard W.M. Jones wrote:
> On Mon, Jul 19, 2010 at 10:33:12AM +0300, Gleb Natapov wrote:
> > On Mon, Jul 19, 2010 at 08:28:02AM +0100, Richard W.M. Jones wrote:
> > > On Mon, Jul 19, 2010 at 09:23:56AM +0300, Gleb Natapov wrote:
> > > > That what I am warring about too. If we are adding device we have to be
> > > > sure such device can actually exist on real hw too otherwise we may have
> > > > problems later.
> > > 
> > > I don't understand why the constraints of real h/w have anything to do
> > > with this.  Can you explain?
> > > 
> > Each time we do something not architectural it cause us troubles later.
> 
> Can you explain more or point to some examples?  I really don't
> understand what these troubles could be.  But I'm prepared to be
> enlightened.
> 
There are many. Look at vmware backdoor interface for instance. Such
beast can't exist on real HW, so now we have to have hacks in emulator
since io operation can change cpu registers. And I am not saying that
what you are proposing can't exist on real HW. If such device can exist
we can do it that way too. The gain is too small though.

> > So what about making initrd smaller? I remember managing two
> > distribution in 64M flash in embedded project.
> 
> The distribution is the size that it is, because (a) it has to be
> based on Fedora and because (b) it has to include a certain number of
> programs.
Why not put then on cdrom or disk?

> 
> The reason for (a) is so that we don't need to compile our own tools
> and we can benefit from bug fixes from Fedora (and contribute bug
> fixes back).  The reason for (b) is that we want to implement a rich
> API[1], and having a rich API means we simply have to include many
> binaries.
> 
> We're already doing a lot of minimization on the image[2], deleting
> man pages, language files, etc., so the image mainly just contains
> binaries and libraries and kernel modules, which we cannot get rid of
> because of (b).  The original pre-minimization image is 600MB or so.
> 

--
                        Gleb.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]