qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Fabrice Bellard
Subject: Re: [Qemu-devel] Re: [PATCH] Add support for a configuration file
Date: Wed, 14 May 2008 18:25:01 +0200
User-agent: Thunderbird 2.0.0.5 (X11/20070727)

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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]