From: Eric Blake <eblake@redhat.com>
To: Anthony Liguori <anthony@codemonkey.ws>
Cc: Anthony Liguori <aliguori@us.ibm.com>,
Gerd Hoffman <kraxel@redhat.com>,
Eduardo Habkost <ehabkost@redhat.com>,
qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH 7/9] qmp: expose a command to query capabilities of config parser
Date: Mon, 19 Mar 2012 14:31:47 -0600 [thread overview]
Message-ID: <4F6797B3.7030405@redhat.com> (raw)
In-Reply-To: <4F6794CF.9070409@codemonkey.ws>
[-- Attachment #1: Type: text/plain, Size: 2464 bytes --]
On 03/19/2012 02:19 PM, Anthony Liguori wrote:
>>> +# @size: an integer followed by either 'K', 'M', 'G', or 'T'.
>>
>> Not quite - I found three different parsers, but none of them match this
>> description.
>
> Heh, I was going by the documentation in the code:
>
> QEMU_OPT_SIZE, /* size, accepts (K)ilo, (M)ega, (G)iga,
> (T)era postfix */
>
>
>> That is, qemu-option.c:parse_option_size() supports 'k'
>> and 'b', as well as omitting a suffix, but does not support 'm'.
>
> TBH, I'd prefer to not document 'k' and 'b' and explicitly document that
> the suffix is optional and bytes is implied (which I thought was implied
> in my documentation, but I can see that it may not be).
>
> I'd rather we support officially support one way of doing things and if
> we support more, do it under the mantra of being liberal in what we accept.
Okay, I can live with documenting less than we accept, but we definitely
need to mention that the suffix is optional, and that when omitted, the
unit is bytes (as originally written, I read it that the suffix was
mandatory, and that there was no way to request bytes). I'm not sure
whether documenting an explicit 'b' for bytes helps or hurts, and I'm
not sure whether adding support for 'p' and 'e' as documented suffixes
makes sense.
>
>> Then
>> there's cmd.c:cvtnum(), which is case-insensitive, and adds 'p' and 'e',
>> but omits 'b'. Then there's the 'o' type in monitor.c that defers to
>> cutils.c:strtosz(), which defaults to bytes but is case-insensitive and
>> supports 'b' but not 'p'. Why are we using three different parsers,
>> anyway?
>
> Yes, I am aware of that, and yes, I'm going to fix it. One bit at a
> time though.
Fair enough :) It's just that I recently fixed a bug in libvirt where
it was using a human interface with no suffix and getting 'M' behavior,
where an explicit 'B' behavior fixed things to use bytes, and I was
quite put off by the inconsistencies and lack of documentation when I
finally discovered that a 'B' suffix did what I wanted. I'm glad that
QMP defaults to 'B', not 'M'. (Libvirt had its own fair share of
inconsistent scaling routines, where some interfaces default to 'k'
instead of bytes, and I recently consolidated libvirt to use a single
scaling routing for much the same reasons.)
--
Eric Blake eblake@redhat.com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 620 bytes --]
next prev parent reply other threads:[~2012-03-19 20:31 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-19 15:09 [Qemu-devel] [RFC PATCH 0/9] qemu capabilities reporting and config changes Anthony Liguori
2012-03-19 15:09 ` [Qemu-devel] [PATCH 1/9] qemu-config: fix -writeconfig when using qemu_opt_set_bool Anthony Liguori
2012-03-19 15:09 ` [Qemu-devel] [PATCH 2/9] qemu-config: friends don't let friends use sscanf Anthony Liguori
2012-03-19 15:09 ` [Qemu-devel] [PATCH 3/9] vl: refactor command line parsing to allow options to be set via config Anthony Liguori
2012-03-19 15:09 ` [Qemu-devel] [PATCH 4/9] vl: mark system configuration options in qemu-options.hx Anthony Liguori
2012-03-19 15:09 ` [Qemu-devel] [PATCH 5/9] vl: enable system configuration to be used Anthony Liguori
2012-03-19 15:09 ` [Qemu-devel] [PATCH 6/9] vl: parse all options via QemuOpts Anthony Liguori
2012-03-19 15:09 ` [Qemu-devel] [PATCH 7/9] qmp: expose a command to query capabilities of config parser Anthony Liguori
2012-03-19 20:10 ` Eric Blake
2012-03-19 20:19 ` Anthony Liguori
2012-03-19 20:31 ` Eric Blake [this message]
2012-03-19 20:41 ` Anthony Liguori
2012-03-19 15:09 ` [Qemu-devel] [PATCH 8/9] vl: add -query-capabilities Anthony Liguori
2012-03-20 7:49 ` Gerd Hoffmann
2012-03-20 10:33 ` Daniel P. Berrange
2012-03-20 19:39 ` Eduardo Habkost
2012-03-19 15:09 ` [Qemu-devel] [PATCH 9/9] Add a management tool writer's guide Anthony Liguori
2012-03-19 16:09 ` [Qemu-devel] [RFC PATCH 0/9] qemu capabilities reporting and config changes Paolo Bonzini
2012-03-19 16:31 ` Anthony Liguori
2012-03-19 16:33 ` Paolo Bonzini
2012-03-19 16:41 ` Anthony Liguori
2012-03-19 16:45 ` Paolo Bonzini
2012-03-19 16:53 ` Anthony Liguori
2012-03-19 17:03 ` Paolo Bonzini
2012-03-20 7:54 ` Gerd Hoffmann
2012-03-20 19:47 ` Eduardo Habkost
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=4F6797B3.7030405@redhat.com \
--to=eblake@redhat.com \
--cc=aliguori@us.ibm.com \
--cc=anthony@codemonkey.ws \
--cc=ehabkost@redhat.com \
--cc=kraxel@redhat.com \
--cc=qemu-devel@nongnu.org \
/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).