From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=59957 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ORTDF-0003Df-8u for qemu-devel@nongnu.org; Wed, 23 Jun 2010 12:54:10 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1ORTDE-0003pc-3k for qemu-devel@nongnu.org; Wed, 23 Jun 2010 12:54:09 -0400 Received: from mx1.redhat.com ([209.132.183.28]:26522) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1ORTDD-0003p5-Pw for qemu-devel@nongnu.org; Wed, 23 Jun 2010 12:54:08 -0400 Received: from int-mx04.intmail.prod.int.phx2.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.17]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o5NGs5E3030888 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 23 Jun 2010 12:54:06 -0400 Date: Wed, 23 Jun 2010 13:43:06 -0300 From: Luiz Capitulino Subject: Re: [Qemu-devel] [PATCH 07/13] Monitor: handle optional '-' arg as a bool Message-ID: <20100623134306.05c39312@redhat.com> In-Reply-To: References: <1277228451-7741-1-git-send-email-lcapitulino@redhat.com> <1277228451-7741-8-git-send-email-lcapitulino@redhat.com> <20100623131431.69ab6ed2@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: qemu-devel@nongnu.org On Wed, 23 Jun 2010 18:31:53 +0200 Markus Armbruster wrote: > Luiz Capitulino writes: > > > On Wed, 23 Jun 2010 17:05:02 +0200 > > Markus Armbruster wrote: > > > >> Luiz Capitulino writes: > >> > >> > Historically, user monitor arguments beginning with '-' (eg. '-f') > >> > were passed as integers down to handlers. > >> > > >> > I've maintained this behavior in the new monitor because we didn't > >> > have a boolean type at the very beginning of QMP. Today we have it > >> > and this behavior is causing trouble to QMP's argument checker. > >> > > >> > This commit fixes the problem by doing the following changes: > >> > > >> > 1. User Monitor > >> > > >> > Before: the optional arg was represented as a QInt, we'd pass 1 > >> > down to handlers if the user specified the argument or > >> > 0 otherwise > >> > > >> > This commit: the optional arg is represented as a QBool, we pass > >> > true down to handlers if the user specified the > >> > argument, otherwise _nothing_ is passed > >> > > >> > 2. QMP > >> > > >> > Before: the client was required to pass the arg as QBool, but we'd > >> > convert it to QInt internally. If the argument wasn't passed, > >> > we'd pass 0 down > >> > > >> > This commit: still require a QBool, but doesn't do any conversion and > >> > doesn't pass any default value > >> > > >> > 3. Convert existing handlers (do_eject()/do_migrate()) to the new way > >> > > >> > Before: Both handlers would expect a QInt value, either 0 or 1 > >> > > >> > This commit: Change the handlers to accept a QBool, they handle the > >> > following cases: > >> > > >> > A) true is passed: the option is enabled > >> > B) false is passed: the option is disabled > >> > C) nothing is passed: option not specified, use > >> > default behavior > >> > >> Because the user monitor can't pass false, the only sensible default > >> behavior is "disabled". > > > > Yes, but I think we shouldn't impose it. I mean, handlers are still free > > to choose an 'enabled' default state. > > They are. Renders the option entirely useless in the user monitor, > though. > > I don't want you to change anything, I just wanted to point out that the > human monitor can't yet support boolean arguments defaulting to true. > QMP can, of course. Exactly, that was my point too.