Re: [libvirt] [Qemu-devel] [PATCH v2] vl.c: Support multiple CPU ranges on -numa option
Markus Armbruster <armbru(a)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).
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