From: Eric Blake <eblake@redhat.com>
To: Kevin Wolf <kwolf@redhat.com>
Cc: qemu-devel@nongnu.org, lbloch@janustech.com, armbru@redhat.com,
qemu-block@nongnu.org, Stefan Hajnoczi <stefanha@redhat.com>,
"Denis V. Lunev" <den@openvz.org>, Max Reitz <mreitz@redhat.com>,
Stefan Weil <sw@weilnetz.de>, Jeff Cody <jcody@redhat.com>
Subject: Re: [Qemu-devel] [PATCH v3 2/6] block: Take advantage of QemuOpt default integers
Date: Fri, 11 Jan 2019 10:28:54 -0600 [thread overview]
Message-ID: <3772838c-a83e-ce76-c0a5-42c2bef2ca24@redhat.com> (raw)
In-Reply-To: <20190111103858.GB5010@dhcp-200-186.str.redhat.com>
[-- Attachment #1: Type: text/plain, Size: 2080 bytes --]
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
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2019-01-11 16:29 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-10 19:18 [Qemu-devel] [PATCH v3 0/6] include: Auto-generate the sizes lookup table Eric Blake
2019-01-10 19:18 ` [Qemu-devel] [PATCH v3 1/6] qemu-option: Allow integer defaults Eric Blake
2019-01-11 14:14 ` Leonid Bloch
2019-01-11 16:23 ` Eric Blake
2019-01-11 18:54 ` Leonid Bloch
2019-01-10 19:18 ` [Qemu-devel] [PATCH v3 2/6] block: Take advantage of QemuOpt default integers Eric Blake
2019-01-11 10:38 ` Kevin Wolf
2019-01-11 16:28 ` Eric Blake [this message]
2019-01-10 19:18 ` [Qemu-devel] [PATCH v3 3/6] Revert "vdi: Use a literal number of bytes for DEFAULT_CLUSTER_SIZE" Eric Blake
2019-01-10 19:42 ` Eric Blake
2019-01-10 19:18 ` [Qemu-devel] [PATCH v3 4/6] qemu: Prefer '(x * MiB)' over 'S_xiB' Eric Blake
2019-01-10 19:18 ` [Qemu-devel] [PATCH v3 5/6] Revert "include: Add a comment to explain the origin of sizes' lookup table" Eric Blake
2019-01-10 19:19 ` [Qemu-devel] [PATCH v3 6/6] Revert "include: Add a lookup table of sizes" Eric Blake
2019-01-10 19:26 ` [Qemu-devel] [Qemu-block] [PATCH v3 0/6] include: Auto-generate the sizes lookup table Eric Blake
2019-01-10 20:21 ` Eric Blake
2019-01-10 20:28 ` Eric Blake
2019-01-11 10:02 ` [Qemu-devel] " Kevin Wolf
2019-01-13 22:50 ` no-reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3772838c-a83e-ce76-c0a5-42c2bef2ca24@redhat.com \
--to=eblake@redhat.com \
--cc=armbru@redhat.com \
--cc=den@openvz.org \
--cc=jcody@redhat.com \
--cc=kwolf@redhat.com \
--cc=lbloch@janustech.com \
--cc=mreitz@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@redhat.com \
--cc=sw@weilnetz.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).