From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MtzWx-0003fW-DZ for qemu-devel@nongnu.org; Sat, 03 Oct 2009 03:59:51 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MtzWs-0003bE-SM for qemu-devel@nongnu.org; Sat, 03 Oct 2009 03:59:51 -0400 Received: from [199.232.76.173] (port=57420 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MtzWs-0003b8-KZ for qemu-devel@nongnu.org; Sat, 03 Oct 2009 03:59:46 -0400 Received: from mx1.redhat.com ([209.132.183.28]:37013) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MtzWs-00023h-5t for qemu-devel@nongnu.org; Sat, 03 Oct 2009 03:59:46 -0400 Message-ID: <4AC7046B.2000505@redhat.com> Date: Sat, 03 Oct 2009 09:59:39 +0200 From: Avi Kivity MIME-Version: 1.0 References: <1254412245-10452-1-git-send-email-lcapitulino@redhat.com> <4AC4D250.3060903@redhat.com> <20091001182108.51a96a17@doriath> In-Reply-To: <20091001182108.51a96a17@doriath> Content-Type: text/plain; charset=UTF-8; format=flowed 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: Luiz Capitulino Cc: aliguori@us.ibm.com, qemu-devel@nongnu.org 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. > 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. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic.