Anthony Liguori <anthony@codemonkey.ws> writes:
Markus Armbruster <armbru@redhat.com> writes:
Related: overwrite something you got from a config file on the command line.
In both your example and mine, we have entirely separate options, and they have perfectly ordinary overwrite semantics: each option overwrites the given keys with the given values. The last key=value wins.
This usage makes sense, and we obviously want to preserve it.
Paolo's example is different only in that it's a silly. Preserving compatibility may mean that once we accepted silly usage, we can't ever reject it. Debatable. Personally, I disagree: I think we could outlaw repeating keys within the same option argument / configuration file section just fine.
Finally, I don't think that we must have fancy-pants syntax to remind users that they're configuring a list. What's the chance of confusion there? What user would expect num_queues=1,num_queues=2 to make num_queues magically become a list?
My fundamental problem here is that we have the same syntax with different meanings depending on the context.
Going back to our original example:
qemu -numa node,nodeid=2,cpus=4
This is certainly ambiguous. Does this mean that you have a single cpu for the node (VCPU 4) or does it mean the node have 4 cpus (presumably ranged 0-3).
Root cause: the name "cpus" can be interpreted as "number of cpus" or as "list of cpus". Fix (if it's worth fixing): use a better name. First one that crossed my mind: "cpu".
Given that ambiguity the following:
qemu -numa node,nodeid=2,cpus=4,cpus=8
Does help the situation. A reasonable person could assume that cpus=8 overrides the previous cpus=4 (as it does elsewhere in QEMU) and
I suspect a reasonable person is blissfully unaware of the fact that he can give the same key several times in a single option argument, let alone what happens when he does. And I still think we could outlaw such repetition if we cared. Besides the command line, there's also the config file. As Paolo explained, "repeated key means list" is established practice there.
therefore assume they were creating a node with 8 CPUS (0-7) instead of two cpus. However:
qemu -numa node,nodeid=2,cpus=4:8
Is much less ambiguous. Granted, it's not immediately obvious whether this is a range specification or a disjoint specification but it's more clear than the previous syntax.
Does it mean CPU 4 and 8? CPU 4 to 8? 8 CPUs starting with 4? If it's less ambiguous, then probably because it's sufficiently greek to make people reach for the manual :) Moreover, no change, thus no improvement for your original example "cpus=4", which you called "certainly ambigous".