On 06/08/10 15:07, Anthony Liguori wrote:
Note that this reverses the ordering for users which want multiple
values (slirp forwarding for example).
And qemu_opt_find seems to have thought about this too:
static QemuOpt *qemu_opt_find(QemuOpts *opts, const char *name)
{
QemuOpt *opt;
QTAILQ_FOREACH_REVERSE(opt, &opts->head, QemuOptHead, next) {
if (strcmp(opt->name, name) != 0)
continue;
return opt;
}
return NULL;
}
Can you show the behavior with commandline arguments only?
The problem I was trying to address can be seen with something like:
-drive file=foo.img,if=virtio,file=bar.img
You get no error, and foo.img is what gets used.
Hmm. I think qemuopts need to carry information about the option
types, whenever it is single-entry or multiple-entry.
Oh, and likewise for the sections. With multiple (unnamed) [device]
sections we want create multiple (id-less) device sections. With
multiple [machine] sections we probably want to merge the options
instead.
Or more specifically:
foo.conf:
[drive]
file=foo.img
if=virtio
id=bar
This would be '[drive "bar"]' without id= line btw.
qemu -readconfig foo.conf -drive file=bar.img,id=bar
IMHO, what's specified next on the command line ought to override what's
in the config.
Or the user's config the global config.
For multi-entry options this will be tricky. What do you expect to
happen here:
global.conf
[net "user"]
type="slirp"
guestfwd=<fw1>
user.conf
[net "user"]
guestfwd=<fw2>
guestfwd=<fw3>
Which forwardings will be active then? All of them? Or will the
user.conf forwardings override the global one?