Anthony Liguori <anthony@codemonkey.ws> writes:
Paolo Bonzini <pbonzini@redhat.com> writes:
Il 27/02/2013 16:42, Anthony Liguori ha scritto:
There's such thing as list support in QemuOpts. The only way QemuOptsVisitor was able to implement it was to expose QemuOpts publicly via options_int.h and rely on a implementation detail.
There are fixed types supported by QemuOpts. It just so happens that whenever qemu_opt_set() is called, instead of replacing the last instance, the value is either prepended or appended in order to implement a replace or set-if-unset behavior.
Fair enough. Nobody said the implementation is pretty.
If we want to have list syntax, we need to introduce first class support for it. Here's a simple example of how to do this.
If it is meant as a prototype only, and the final command-line syntax would be with repeated keys, that's okay. I think that Eduardo/Markus/I are focusing on the user interface, you're focusing in the implementation.
No, I'm primarily motivated by the UI and am assuming that ya'll are arguing based on the implementation today.
Your assumption is incorrect :)
Repeating keys is quite mad. Here are some examples:
qemu -numa node=1,node=2,cpus=2,cpus=3
What would a user expect that that would mean.
I figure you mean -numa node,nodeid=1,nodeid=2,cpus=2,cpus=3 Parameter nodeid is int-valued, therefore repeating it is either an error, or the last one wins. Matter of taste. Currently, we do the latter. Parameter cpus is list-valued, therefore the values accumulate. We already do that. Taken together, this configures node 1 to use cpus 2 and 3.
What about:
[numa] node=1 cpus=2 cpus=3
qemu -readconfig numa.cfg -numa node=1,cpus=1
I figure you mean [numa] nodeid=1 cpus=2 cpus=3 qemu -readconfig numa.cfg -numa node,nodeid=1,cpus=1 The config file configures node 1 to use cpus 2 and 3. The command line configures node 1 to use cpus 1. QemuOpts can optionally be made to merge options with the same ID. We use that in cases like -machine, where multiple options make no sense, but merging them does. Merging options doesn't make sense for -numa. Therefore, configuration file and command line are *not* merged. In particular, the two cpus lists are not merged. So, what we have is two conflicting bits of configuration for the same thing. That's not a new problem, we got that everywhere. Either treat as error, or let the last one win. Matter of taste. Currently, we do the latter.
I'm pretty sure you won't be able to say without looking at the source code.
I hereby certify that I did not look at the source code, only at help output. So there.
Now what about ranges? I'm pretty sure that what a user really wants to say is:
qemu -numa node=1,cpus=0-3:8-11
This is easy to do with the patch I sent. We can add range support integer lists by just adding a check for '-' before doing dispatch. That's a heck of a lot nicer than:
qemu -numa node=1,cpus=0,cpus=1,cpus=2,cpus=3,cpus=8,cpus=9,cpus=10,cpus=11
Let me pick up the baby you just threw out with the bathwater for you: qemu -numa node,nodeid=1,cpus=0-3,cpus=8-11
With respect to escaping, for string lists (the only place where this point is even relevant), we can simply support escaping. But I'd like to hear a use-case for a string list first.
There is no need for the syntactic warts you so cavalierly propose. Whenever you do key=X:Y, I can do key=X,key=Y. Whatever semantics you propose for the former, I'll propose for the latter.