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: Anthony Liguori
Subject: Re: [Qemu-devel] Re: [PATCH] Add support for a configuration file
Date: Wed, 14 May 2008 10:09:16 -0500
User-agent: Thunderbird 2.0.0.14 (X11/20080505)

Paul Brook wrote:
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

What I don't like about the ide0.primary.master syntax is that there isn't enough structure. I would prefer:

alias hda ide,bus=0,primary,master

If you combine this with your magic variable idea, you could also do:

alias hda ide,bus=0,unit=$next

But you could also just fold that into Fabrice's syntax (which I prefer):

hda.class = ide,bus=0,unit=$next
hda.type = disk
hda.file = foo.img

If you then default bus, and unit, you can just write:

hda.class = ide
hda.type = disk
hda.file = foo.img

And better yet, you could even allow for something like:

hda.class = ide
hda.bus = 0
hda.unit = 0
hda.type = disk
hda.file = foo.img

So I really actually prefer Fabrice's syntax because there is much more structure. I think it's a good idea to allow .class to contain multiple properties and to basically establish an alias. This way, you could predefine a bunch of aliases for today's parameters like hda, hdb, etc.

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.

I think if we choose a syntax we like, we can start using that pretty easily. We'll have to start adjusting option names keeping them only valid on the command line (for things like -m). However, I think it would grow pretty well into a machine description mechanism.

Regards,

Anthony Liguori

Thoughts?

Paul





reply via email to

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