> 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. This may require some internal restructuring to allow the machine descriptions to feed into the user config file. Thoughts? Paul ------------------------------------------------------------------------- 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
