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. > 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). -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature