On 1/11/19 4:38 AM, Kevin Wolf wrote: > Am 10.01.2019 um 20:18 hat Eric Blake geschrieben: >> Instead of defining an integer to a default string value (where we >> have to be careful how we spelled the integer because of the use of >> stringify), populate a default integer value instead. >> >> Drop a useless stringify(0); a missing default is just as easy to >> interpret as 0 as an explicit string 0. >>
>> {
>> .name = VHDX_BLOCK_OPT_BLOCK_SIZE,
>> .type = QEMU_OPT_SIZE,
>> - .def_value_str = stringify(0),
>> .help = "Block Size; min 1MB, max 256MB. " \
>> "0 means auto-calculate based on image size."
>> },
>
> Before the patch:
> $ ./qemu-img create -f vhdx /tmp/test.vhdx 64M
> Formatting '/tmp/test.vhdx', fmt=vhdx size=67108864 log_size=1048576
> block_size=0
>
> After the patch:
> $ ./qemu-img create -f vhdx /tmp/test.vhdx 64M
> Formatting '/tmp/test.vhdx', fmt=vhdx size=67108864 log_size=1048576
>
> Intentional?
Yes. Well, sort of. A default of 0 is automatic, so right now, our help
output omits all variables with an implicit default of 0. We have no
way to tell the difference between an explicit integer default of 0 and
an implicit one (we did with strings, but the point of the series is to
store default integers as integers rather than as strings), so we could
work around that by adding even more to QemuOpts to record a bool of
whether an int of 0 should be listed as an explicit zero in our help
output. Or we could state that listing a default of zero doesn't help
anyone. Or we could list ALL variable defaults (even the ones that
default to implicit 0) rather than the current code that special-cases
output to omit variables left at their implicit default, but that may
change output in the other direction (more output where we are now
silent - although that may not be a bad thing).
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization: qemu.org | libvirt.org
signature.asc
Description: OpenPGP digital signature
