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