From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48406) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VtfK6-0007T3-Uo for qemu-devel@nongnu.org; Thu, 19 Dec 2013 10:15:45 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VtfK0-00024l-Qh for qemu-devel@nongnu.org; Thu, 19 Dec 2013 10:15:38 -0500 Received: from mx1.redhat.com ([209.132.183.28]:48353) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VtfK0-00024a-B5 for qemu-devel@nongnu.org; Thu, 19 Dec 2013 10:15:32 -0500 From: Markus Armbruster References: <1385001528-12003-1-git-send-email-imammedo@redhat.com> <1385001528-12003-6-git-send-email-imammedo@redhat.com> <87r4aaxdqt.fsf@blackfin.pond.sub.org> <20131125163642.4d832fd5@nial.usersys.redhat.com> <20131125160337.GB10326@redhat.com> <52937BA2.6020605@redhat.com> <52937E44.10503@redhat.com> <20131219144037.GB17508@redhat.com> Date: Thu, 19 Dec 2013 16:14:56 +0100 In-Reply-To: <20131219144037.GB17508@redhat.com> (Michael S. Tsirkin's message of "Thu, 19 Dec 2013 16:40:37 +0200") Message-ID: <87r498oosv.fsf@blackfin.pond.sub.org> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Qemu-devel] [PATCH 05/27] qapi: add SIZE type parser to string_input_visitor List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: peter.maydell@linaro.org, aliguori@amazon.com, stefanb@linux.vnet.ibm.com, hutao@cn.fujitsu.com, quintela@redhat.com, mjt@tls.msk.ru, qemu-devel@nongnu.org, mdroth@linux.vnet.ibm.com, vasilis.liaskovitis@profitbricks.com, chegu_vinod@hp.com, kraxel@redhat.com, stefanha@redhat.com, Paolo Bonzini , Igor Mammedov , marcel.a@redhat.com, lcapitulino@redhat.com, afaerber@suse.de "Michael S. Tsirkin" 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.