[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [Bug 1707297] [NEW] qemu became more picky parsing -m o
From: |
Markus Armbruster |
Subject: |
Re: [Qemu-devel] [Bug 1707297] [NEW] qemu became more picky parsing -m option |
Date: |
Mon, 31 Jul 2017 15:28:45 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux) |
Eric Blake <address@hidden> writes:
> On 07/31/2017 03:34 AM, Markus Armbruster wrote:
>> John Florian <address@hidden> writes:
>>
>>> Public bug reported:
>>>
>>> With qemu-kvm-2.9.0-3.fc26.x86_64 I am no longer to specify the memory
>>> size using something like "-m 1.00000GiB" but with qemu-
>>> kvm-2.7.1-7.fc25.x86_64 I could without any problem. I now get an error
>>> message like:
>>>
>>> qemu-system-x86_64: -m 1.00000GiB: Parameter 'size' expects a non-negative
>>> number below 2^64
>>> Optional suffix k, M, G, T, P or E means kilo-, mega-, giga-, tera-, peta-
>>> and exabytes, respectively.
>>>
>>>
>>> Is this expected or a regression?
>>
>> We recognize suffix "G". Before commit 75cdcd1 (v2.9.0), trailing
>> garbage after a recognized suffix was silently ignored. "1.0G",
>> "1.0GiB", "1.0Garbage-trucks-of-RAM" were all the same to QEMU. No
>> more.
>>
>> All clear?
>
> That said, virsh from libvirt manages to recognize 'G' and 'GiB' as
> synonyms (powers of 2), as well as 'GB' (powers of 10); we could justify
> patching qemu's parser to accept more valid suffixes, particularly since
> 'GiB' is a typical suffix that has seen use (in spite of it not being
> documented).
I wouldn't object to such a patch, as long as it doesn't regress
consistency. Easy if we do "number with suffix" in just one place. We
might already do it, but I can't say offhand. Also, the patch probably
shouldn't change qemu_strtosz_metric().