qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v2] vl.c: Support multiple CPU ranges on -numa o


From: Markus Armbruster
Subject: Re: [Qemu-devel] [PATCH v2] vl.c: Support multiple CPU ranges on -numa option
Date: Thu, 28 Feb 2013 14:09:13 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1 (gnu/linux)

Anthony Liguori <address@hidden> writes:

> Paolo Bonzini <address@hidden> writes:
>
>> Il 27/02/2013 18:08, Anthony Liguori ha scritto:
>>>> >
>>>> > No, no, no.  This makes ':' special, which means you can't have lists of
>>>> > anything containing ':'.  Your cure is worse than the disease.  Let go
>>>> > of that syntactic high-fructose corn syrup, stick to what we have and
>>>> > works just fine, thank you.
>>> Yes, there *must* be special syntax.  If we're treating something
>>> special, then we should indicate to the user that it's special.
>>> 
>>> Specifically, a list of integers should look distinctly different than
>>> overriding a previously specified integer.
>>
>> The solution is "there is no way to override a previously specified
>> key".  Something like "-device
>> virtio-scsi-pci,num_queues=1,num_queues=2" now works, let's make it an
>> error instead.
>
> That breaks compatibility.  The above may seem silly but consider:
>
> qemu -device virtio-scsi-pci,num_queues=1,id=foo \
>      -set device.foo.num_queues=2
>
> This is more common than you would think primarily as a way to override
> options that libvirt has set either via the qemu extra args tag or a
> script wrapper of qemu.

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?



reply via email to

[Prev in Thread] Current Thread [Next in Thread]