From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=40849 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1P1g05-0001KE-2U for qemu-devel@nongnu.org; Fri, 01 Oct 2010 09:51:19 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1P1fz8-000358-RS for qemu-devel@nongnu.org; Fri, 01 Oct 2010 09:50:09 -0400 Received: from mx1.redhat.com ([209.132.183.28]:52293) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1P1fz8-00034u-KE for qemu-devel@nongnu.org; Fri, 01 Oct 2010 09:49:14 -0400 Date: Fri, 1 Oct 2010 10:49:06 -0300 From: Luiz Capitulino Message-ID: <20101001104906.498b9cf6@doriath> In-Reply-To: <4CA5E29F.4030606@linux.vnet.ibm.com> References: <1285880180-29724-1-git-send-email-lcapitulino@redhat.com> <1285880180-29724-11-git-send-email-lcapitulino@redhat.com> <4CA5E29F.4030606@linux.vnet.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [PATCH 10/19] QMP: Introduce query commands dispatch table List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Anthony Liguori , qemu-devel@nongnu.org, armbru@redhat.com On Fri, 01 Oct 2010 08:31:11 -0500 Anthony Liguori wrote: > On 09/30/2010 03:56 PM, Luiz Capitulino wrote: > > The new table is a copy of HMP's table, containing only QObject > > handlers. > > > > In the near future HMP will be making QMP calls and then we will > > be able to drop QObject handlers from HMP's table. > > > > > From now on, QMP and HMP have different query command dispatch > > tables. > > > > I like this series a lot and I think it's ready to merge. > > But I wonder, why have a separate qmp_query_cmds table? Why not just > fold the query commands into qmp_cmds? Yes, that will be done shortly, but in a different series. I'm not doing it in this series because it's necessary to change the signature of all those functions which would make this series too large and harder to review. On a related note: I have more monitor patches in my queue. I'm building and testing them right now. I'm planning to send a pull request of all pending monitor patches later today. So, if you prefer, you can wait for that pull request instead of merging this series alone. It will generate some noise on the list though, as I think it's good practice to resend patches in a pull request to the list.