qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] Re: [PATCH 0/22] Refactor machine support


From: Anthony Liguori
Subject: Re: [Qemu-devel] Re: [PATCH 0/22] Refactor machine support
Date: Wed, 09 Jun 2010 15:52:35 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100423 Lightning/1.0b1 Thunderbird/3.0.4

On 06/09/2010 03:47 PM, Blue Swirl wrote:
On Wed, Jun 9, 2010 at 2:30 PM, Paul Brook<address@hidden>  wrote:
Because at some point the base tree will have to be written in C.
No. You can start with a completely empty machine.
We don't/shouldn't need any machine specific C code.
I think you're missing the argument.  I should be possible to create a
machine entirely from a FDT or via -device options.

However, to continue to support the interfaces that we support today, it
will be necessary to have C code that manipulates a base device tree.

When a user specifies '-M pc -hda foo.img'  verses '-M versatilepb -hda
foo.img', the equivalent are two very different operations on a device
tree.  The former adds an ide disk to the default controller and the
later potentially creates a new scsi bus and then adds a disk to a
specific bus.
AFAICS the current commandline options only result in simple addition of
devices. They might add slightly different devices in slightly different
places, but that's easy to accommodate by having the machine define a few
standard device/bus IDs.

IMO it's even more lame if -hda shops working when you supply a device tree.
The tree supplied by the user should label a bus node with a property
'QEMU,hda'. The C version (called by the board) would be something
like setprop("/i440fx/pci.0/ide.0", "QEMU,hda"). QEMU should search
the device tree for such labels at startup.

That works for the very simple case of -hda, but what do you do for:

-drive file=foo.img,bus=0,index=2

I think it's possible to come up with some form of solution once you start adding synthetic properties or dummy devices but ultimately I think it pollutes the device tree. I think the easiest way to support the interfaces we provide now is to just code the device tree manipulation in C.

Regards,

Anthony Liguori



reply via email to

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