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

[Paul Brook <paul@codesourcery.com>]

> >> 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 don't see how that is any harder. I'm assuming that -hda is a trivial alias 
for -drive bus=0,index=0. Fact is that -drive supports a very limited set of 
operations. Figuring out the default interface is easy - use whatever exists 
on the machine. Creating IDE disks is easy, just add them to the existing IDE 
bus.  For SCSI/virtio you might need to add a HBA first, but that's also 
fairly trivial.  Most other interfaces (sd, pflash) don't do automagical 
device creation to start with - if you don't specify an image then you get an 
empty/disconnected device.

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

I disagree. If programmatic machine construction/manipulation was sufficient 
then we wouldn't need device trees at all.  Current qemu supports an extremely 
limited set of machines.  Bear in mind that x86 PCs are, pretty much by 
definition, approximately all the same to start with.  Once you start looking 
at other platforms (e.g. arm boards) you realise just how cripplingly 
restrictive the this is.  Restricting -hda, -drive, etc. and similar to a 
small subset of built-in machines is IMO and unacceptably poor solution.

Some of your arguments seem to be self-fulfilling prophecies. If you design 
your new option structure around a magical self-morphing device tree then it's 
unlikely that this will work with user specified device trees.  I believe the 
current set of commandline options are sufficient abstract that they do not 
dictate a particular implementation.

Paul