[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?
- Re: [Qemu-devel] [PATCH v2] vl.c: Support multiple CPU ranges on -numa option, (continued)
- Re: [Qemu-devel] [PATCH v2] vl.c: Support multiple CPU ranges on -numa option, Eduardo Habkost, 2013/02/27
- Re: [Qemu-devel] [PATCH v2] vl.c: Support multiple CPU ranges on -numa option, Markus Armbruster, 2013/02/27
- Re: [Qemu-devel] [PATCH v2] vl.c: Support multiple CPU ranges on -numa option, Anthony Liguori, 2013/02/27
- Re: [Qemu-devel] [PATCH v2] vl.c: Support multiple CPU ranges on -numa option, Paolo Bonzini, 2013/02/27
- Re: [Qemu-devel] [PATCH v2] vl.c: Support multiple CPU ranges on -numa option, Anthony Liguori, 2013/02/27
- Re: [Qemu-devel] [PATCH v2] vl.c: Support multiple CPU ranges on -numa option, Paolo Bonzini, 2013/02/27
- Re: [Qemu-devel] [PATCH v2] vl.c: Support multiple CPU ranges on -numa option,
Markus Armbruster <=
- Re: [Qemu-devel] [PATCH v2] vl.c: Support multiple CPU ranges on -numa option, Anthony Liguori, 2013/02/28
- Re: [Qemu-devel] [PATCH v2] vl.c: Support multiple CPU ranges on -numa option, Paolo Bonzini, 2013/02/28
- Re: [Qemu-devel] [PATCH v2] vl.c: Support multiple CPU ranges on -numa option, Markus Armbruster, 2013/02/28