Re: [Qemu-devel] [PATCH 05/27] qapi: add SIZE type parser to string_input_visitor

[Markus Armbruster]

"Michael S. Tsirkin" <address@hidden> writes:

> On Mon, Nov 25, 2013 at 09:43:48AM -0700, Eric Blake wrote:
>> On 11/25/2013 09:32 AM, Paolo Bonzini wrote:
>> 
>> >> Yes please. Firing up a calculator to figure out how much is 1G is not
>> >> friendly, neither is firing it up to figure out what did management do
>> >> with QMP. It should be a text based interface not a binary one.
>> 
>> Right now, QMP takes an 'int', which does not allow a suffix.  Libvirt
>> prefers passing a value in 'bytes', rather than risking confusion on
>> whether a value in G was rounded (up, down? to nearest power of 10 or
>> power of 2?).  Unfortunately, yes, that means you need a calculator when
>> parsing QMP logs to see whether the 1073741824 passed by libvirt is the
>> 1G you had in mind.
>> 
>> HMP, qtest, and any other decent shell around raw QMP is more than
>> welcome to provide human-usable wrappers that takes "1G" as a string and
>> turns it into the raw int used by the underlying QMP.  In fact, I
>> encourage it.
>
> How will it know 1G is not e.g. an ID?
>
> We can invent rules like "IDs should not start with a number", but these
> rules are better enforced in a single place for consistency, and it's
> likely too late to enforce that in HMP.

This isn't how the human monitor works.

Its argument parsing is guided by the command's args_type, which
declares argument names and type codes.  For instance, type code 's'
expects a string argument (may be enclosed in quotes), 'i' a 32-bit
integer argument, 'o' a size argument (may be followed by a suffix such
as 'G').

If the current argument has type code 'o', then 1G is interpreted as the
number 2^30.  With type code 's', it's the string "1G".

As to rules for IDs: IDs are typically defined via QemuOpts, which
restricts them to letters, digits, '-', '.', '_', starting with a
letter.

>> > This is unfortunately a counter-example to the rule that HMP commands
>> > should always be implemented in terms of their QMP counterparts.  I do
>> > not believe this is really a problem.  It can be fixed later; for now, I
>> > think "perfect is the enemy of good" applies.
>> 
>> Hey - I just realized that now that we have anonymous unions, we could
>> theoretically extend QMP to allow a union between 'int' and 'string' -
>> if an 'int' is passed, it is in bytes; if a 'string' is passed, then
>> parse it the way HMP would (so the string "1G" would be equivalent to
>> the raw int 1073741824).  But I don't know if it will help you (libvirt
>> will still prefer to use raw ints in any QMP log you read off of libvirt
>> interactions).
>
> Yes, I think that would address the issue.

I object, because it goes against the design of QMP.