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