Paul Brook wrote:
>> I suggested it because my original plan for the configuration file was
>> based on this syntax with a strong inspiration from the OpenFirmware
>> device tree. The idea was that the object name ("drive" here) had no
>> hardcoded meaning, except for some predefined object names in order to
>> keep a kind of backward compatibility with the current QEMU options. In
>> order to create a new drive for example, you just have to do:
>>
>> mydrive.class=drive
>> mydrive.if=scsi
>> mydrive.file=abc.img
>>
>> the "class" field is used to select the device model. Then all the other
>> parameters are used to initialize the device model. That way it is
>> possible to keep the compatibility with the existing options and add a
>> provision to instanciate arbitrary new device models, such as:
>
> I like the idea, but I'm not so keen on the automatic allocation. I generally
> prefer explicit declaration over implicit things. The latter makes it very
> easy to not notice when you make a typo.
>
> It sounds like what you really want is something similar to an OF device
> tree.
> So you have something like:
>
> # pciide0 may be an alias (possibly provided by qemu)
> # e.g. pci0.slot1.func1.ide
> alias hda ide0.primary.master
>
> hda.type=disk
> hda.file=foo.img
>
> You can then define some form of magic aliases that select the next unused
> device. e.g.
>
> alias mydrive $next_ide_disk
>
> IMHO This provides the flexibility and structure that Fabrice is talking
> about, and with suitable aliases can be made to look a lot like the existing
> options.
Right. It is my intent too to allow aliases to keep the same "familiar"
names as the command line.
Moreover the tree you suggest is necessary in order to derive the device
instanciation order. In my idea, the tree has no relation with the
actual device connections which are specified by explicit fields such as
slots, functions, interface index, disk indexes or anything else.
An interesting shortcut can be to automatically define a field "index"
if the device name terminates with a number (if I remember correctly
OpenFirmware does something like this).
The initialization phase would consist in traversing the tree
recursively and by instanciating a device for all nodes containing a
"class" (or "type" if you prefer) field. The parents would be
instanciated before the children to ensure a coherent initialization order.
Regarding the syntax, quoted strings must be supported of course. I
don't think there is a great complexity in that :-) A cpp like
preprocessing can be added, but it can be done later.
> This may require some internal restructuring to allow the machine
> descriptions
> to feed into the user config file.
Hopefully it is not necessary to fully implement the proposal now. But
ultimately, each QEMU device would have to register its class name and
an instanciation function. The machine descriptions would have to
predefine some object names so that the user can modify parameters.
Regards,
Fabrice.
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
