Re: [Qemu-devel] Re: [PATCH] Add support for a configuration file

[Paul Brook <paul@xxxxxxxxxxxxxxxx>]

> 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

-------------------------------------------------------------------------
 
 

_______________________________________________
kvm-devel mailing list
kvm-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/kvm-devel