On Thu, Dec 19, 2013 at 04:14:56PM +0100, Markus Armbruster wrote: > "Michael S. Tsirkin" <m...@redhat.com> 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.
Yes but we were talking about a friendly shell for qemu using QMP as a backend. > 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.
