Anthony Liguori <anthony@xxxxxxxxxxxxx> writes:
> Paolo Bonzini <pbonzini@xxxxxxxxxx> 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.
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list