Eric Blake <ebl...@redhat.com> writes: > 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.
This is by design. > 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. Me too, as long as the units suffixes are used consistently. >> 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. I don't get why there's a counter-example. The rules are 1. A QMP command handler (which needs to be of type int (*)(Monitor *, const QDict *params, QObject **ret_data)) should be a thin wrapper around a function with a type appropriate for C that contains all the logic. The wrapper merely translates. 2. HMP commands are to be built on top of these functions, not their handler wrappers. > 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). Please do not complicate QMP's wire format just to help humans deal with it. It's for machines. We intentionally picked a machine-readable syntax that is still readable and writable for humans (feature!), but that's as far as we should go in supporting human use.
