From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NImyI-0007Kj-Os for qemu-devel@nongnu.org; Thu, 10 Dec 2009 12:38:34 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NImyD-0007DQ-5F for qemu-devel@nongnu.org; Thu, 10 Dec 2009 12:38:33 -0500 Received: from [199.232.76.173] (port=57526 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NImyC-0007D9-LS for qemu-devel@nongnu.org; Thu, 10 Dec 2009 12:38:28 -0500 Received: from mx1.redhat.com ([209.132.183.28]:18478) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NImyD-00081z-0r for qemu-devel@nongnu.org; Thu, 10 Dec 2009 12:38:29 -0500 Date: Thu, 10 Dec 2009 17:38:13 +0000 From: "Daniel P. Berrange" Subject: Re: [Qemu-devel] [PATCH 10/19] monitor: Convert do_info_name() to QObject Message-ID: <20091210173813.GA23219@redhat.com> References: <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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091210145457.25ba1f09@doriath> Reply-To: "Daniel P. Berrange" List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Luiz Capitulino Cc: qemu-devel@nongnu.org, Anthony Liguori , Avi Kivity , Markus Armbruster On Thu, Dec 10, 2009 at 02:54:57PM -0200, 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. > > 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? > > 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. > > So, what I arguably did wrong here was starting the conversion > work before defining all these rules. > > 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. Please don't do that. libvirt is adding support for new features all the time. I don't want to be in the situation where we can't add a new feature because it is missing in the JSON impl. If we're going to provide a supported JSON monitor it needs to have all the commands converted, otherwise we'll have to stick with using the text based monitor. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|