From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MunQi-0001SH-Dp for qemu-devel@nongnu.org; Mon, 05 Oct 2009 09:16:44 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MunQf-0001Rm-08 for qemu-devel@nongnu.org; Mon, 05 Oct 2009 09:16:44 -0400 Received: from [199.232.76.173] (port=54991 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MunQe-0001Rd-Ql for qemu-devel@nongnu.org; Mon, 05 Oct 2009 09:16:40 -0400 Received: from mx1.redhat.com ([209.132.183.28]:36108) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MunQe-0002uk-8T for qemu-devel@nongnu.org; Mon, 05 Oct 2009 09:16:40 -0400 Date: Mon, 5 Oct 2009 10:16:31 -0300 From: Luiz Capitulino Message-ID: <20091005101631.3243e69f@doriath> In-Reply-To: <4AC7046B.2000505@redhat.com> References: <1254412245-10452-1-git-send-email-lcapitulino@redhat.com> <4AC4D250.3060903@redhat.com> <20091001182108.51a96a17@doriath> <4AC7046B.2000505@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [PATCH v1 00/14]: Initial QObject conversion List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: aliguori@us.ibm.com, qemu-devel@nongnu.org On Sat, 03 Oct 2009 09:59:39 +0200 Avi Kivity wrote: > On 10/01/2009 11:21 PM, Luiz Capitulino wrote: > >> Regarding info, I think the machine protocol should manage it as > >> separate commands ("info-cpus" instead of "info"("cpus")). Having a > >> function which returns wildly different return types (a string for > >> version, a device tree for qdev) is unwieldy. > >> > > I agree and I think this approach would make my life easier. > > > > I was thinking more of client writers. I see. > > The problem though is how to properly refactor the code so that > > we don't conflict with the user's 'info cpus' command. > > > > I will think about it, but would be good to decide this before > > mass conversion. > > > > One approach would be to have two command tables, one for ordinary > commands and one for info commands. The machine monitor can scan the > two tables sequentially, while the human monitor will only scan the > first table, and the second as a response to an 'info' command. I thought about doing something similar, as we already have a different table for 'info' commands. The disadvantage of this approach though, is that we would have to handle 'info' handlers differently, ie, we would have to add special cases in common code. Today, a 'info' command is treated as any other command, but its handler (do_info()) calls the correct handler. Not sure if this is a big deal, though.