Markus Armbruster <armbru@xxxxxxxxxx> 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).
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
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.
Regards,
Anthony Liguori
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list