From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NImPn-0002vh-Sc for qemu-devel@nongnu.org; Thu, 10 Dec 2009 12:02:55 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NImPj-0002sN-Jy for qemu-devel@nongnu.org; Thu, 10 Dec 2009 12:02:55 -0500 Received: from [199.232.76.173] (port=54287 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NImPj-0002s6-FT for qemu-devel@nongnu.org; Thu, 10 Dec 2009 12:02:51 -0500 Received: from mx1.redhat.com ([209.132.183.28]:8569) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NImPj-0004KX-IS for qemu-devel@nongnu.org; Thu, 10 Dec 2009 12:02:51 -0500 Message-ID: <4B2129AD.3080701@redhat.com> Date: Thu, 10 Dec 2009 19:02:37 +0200 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 10/19] monitor: Convert do_info_name() to QObject References: <1260376078-8694-1-git-send-email-lcapitulino@redhat.com> <1260376078-8694-11-git-send-email-lcapitulino@redhat.com> <20091210095237.38cafe5c@doriath> <4B20F003.6070409@linux.vnet.ibm.com> <4B2119F9.6010003@redhat.com> <4B211BE2.60907@linux.vnet.ibm.com> <4B211D6F.7020906@redhat.com> <4B211FDF.4070509@linux.vnet.ibm.com> <4B2120C6.1020004@redhat.com> <20091210145457.25ba1f09@doriath> In-Reply-To: <20091210145457.25ba1f09@doriath> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Luiz Capitulino Cc: Anthony Liguori , Markus Armbruster , qemu-devel@nongnu.org On 12/10/2009 06:54 PM, Luiz Capitulino wrote: > On Thu, 10 Dec 2009 18:24:38 +0200 > Avi Kivity wrote: > > >>> Let me put it another way, I don't think adding null to the json >>> parser and incorporating it into this command is a good idea at this >>> stage in the release so if we want to do something like this, we need >>> to defer it to 0.13. >>> >>> I agree there are some instances where null could be useful. I think >>> we can get away without it here though. >>> >> For 'name', definitely, since it's known to exist. It would be nice to >> have consistency in how features are presented, though. >> > Following what you propose, if it's known to exist then we should > never return an empty dict. > Right, but if we can't support null (why?) then we can make an exception for 'name'. > There are other commands that might require adjustments, for example > 'info kvm' has a 'present' key. If QEMU is built w/o KVM support, then > this key will be 'false'. Should we return an empty dict then? > No. > HPET is another example, currently it's only compiled in if the > target is i386. Otherwise the command won't even be available, and > we have more commands with conditional features/compilation. > > That's fine, as long as command availability is discoverable. > So, what I arguably did wrong here was starting the conversion > work before defining all these rules. > On the other hand, we can often only find out something by implementing it incorrectly first. > An option we have is: libvirt actually uses four or five of those > info commands. So, we could drop all the rest and guarantee that > only those libvirt ones are 100% correct. > My worry is with the commands that parse or emit comma-separated option strings. -- error compiling committee.c: too many arguments to function