[Top][All Lists]
[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
- Re: [kvm-devel] [Qemu-devel] Re: [PATCH] Add support for a configuration file, (continued)
- Re: [kvm-devel] [Qemu-devel] Re: [PATCH] Add support for a configuration file, Andreas Färber, 2008/05/14
- Re: [kvm-devel] [Qemu-devel] Re: [PATCH] Add support for a configuration file, Daniel P. Berrange, 2008/05/14
- Re: [kvm-devel] [Qemu-devel] Re: [PATCH] Add support for a configuration file, Andreas Färber, 2008/05/14
- Re: [kvm-devel] [Qemu-devel] Re: [PATCH] Add support for a configuration file, Fabrice Bellard, 2008/05/14
- Re: [kvm-devel] [Qemu-devel] Re: [PATCH] Add support for a configuration file, Luca Barbato, 2008/05/17
- Re: [kvm-devel] [Qemu-devel] Re: [PATCH] Add support for a configuration file, Daniel P. Berrange, 2008/05/14
- Re: [Qemu-devel] Re: [PATCH] Add support for a configuration file,
Anthony Liguori <=
- Re: [Qemu-devel] Re: [PATCH] Add support for a configuration file, Paul Brook, 2008/05/14
- Re: [Qemu-devel] Re: [PATCH] Add support for a configuration file, Fabrice Bellard, 2008/05/14
Re: [Qemu-devel] Re: [PATCH] Add support for a configuration file, andrzej zaborowski, 2008/05/14
Re: [Qemu-devel] [PATCH] Add support for a configuration file, Erik de Castro Lopo, 2008/05/15
Re: [Qemu-devel] [PATCH] Add support for a configuration file, Anthony Liguori, 2008/05/15