From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=43436 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PPxQl-0006GP-IT for qemu-devel@nongnu.org; Tue, 07 Dec 2010 08:20:13 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PPxOe-0004y6-98 for qemu-devel@nongnu.org; Tue, 07 Dec 2010 08:18:07 -0500 Received: from mx1.redhat.com ([209.132.183.28]:37415) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PPxOe-0004y2-1w for qemu-devel@nongnu.org; Tue, 07 Dec 2010 08:15:56 -0500 Date: Tue, 7 Dec 2010 11:15:47 -0200 From: Luiz Capitulino Subject: Re: [Qemu-devel] [PATCH 01/25] QMP: Rename query handlers Message-ID: <20101207111547.13c766dc@doriath> In-Reply-To: References: <1291659852-23028-1-git-send-email-lcapitulino@redhat.com> <1291659852-23028-2-git-send-email-lcapitulino@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Miguel Di Ciurcio Filho Cc: aliguori@us.ibm.com, qemu-devel@nongnu.org, armbru@redhat.com On Tue, 7 Dec 2010 10:28:25 -0200 Miguel Di Ciurcio Filho wrote: > On Mon, Dec 6, 2010 at 4:23 PM, Luiz Capitulino = wrote: > > Query handlers still carry their human monitor name. This commit > > renames all of them to a more QMP-like name. > > > > For example, do_info_version() is renamed to qmp_query_version(). > > - * do_info_balloon(): Balloon information > > + * qmp_query_balloon(): Balloon information > > =C2=A0* > > =C2=A0* Make an asynchronous request for balloon info. =C2=A0When the r= equest completes > > =C2=A0* a QDict will be returned according to the following specificati= on: > > @@ -106,7 +106,7 @@ void monitor_print_balloon(Monitor *mon, const QObj= ect *data) > > =C2=A0* =C2=A0 "major_page_faults": 142, "minor_page_faults": 239245, > > =C2=A0* =C2=A0 "free_mem": 1014185984, "total_mem": 1044668416 } > > =C2=A0*/ > > -int do_info_balloon(Monitor *mon, MonitorCompletion cb, void *opaque) > > +int qmp_query_balloon(Monitor *mon, MonitorCompletion cb, void *opaque) > > =C2=A0{ >=20 > If the idea is to detach the human monitor from the QMP API, is there > any reason to keep passing `Monitor *mon` to qmp_* functions? No, I should drop it soon. > In some parts of the code NULL is being passed. Yes, this series is just a first step. We have lots of work to do and somet= imes I don't know what to do next, but the plan looks more or less like this: 1. Change info handlers to make directly QMP calls This series. =20 2. Move all qmp_query_* functions from the qmp_query_cmds[] table to the qmp-commands.hx one I have this almost ready, but I'm wondering if I should take the opportunity to drop the monitor object in this series... 3. Split all monitor commands into a human monitor part and a QMP part, the QMP part becomes the QMP API and the human monitor just calls it I have started doing this (maybe it's in an RFC state), but trust me, it's very difficult to split some handlers. One example is the do_change() one. Yes, a clearly human targeted command. So the question is: should we split such a handler or should we just add a good replacement? If we choose to add a replacement, then it's going to take a lot of time to have the QMP vs. HMP separation done. If we split the handler, then we'll have to live with complex, ugly code for a while. 4. Make handlers return an error object This is the new error infrastructure work, Markus will work on this. 5. Drop all Monitor object usage by QMP by introducing a QMP object We won't pass the QMP object to handlers, it's just our interface with the chardev layer that will change. 6. Add async command infrastructure Not necessary step 6, we'll probably be able to do it sooner. 7. Split the monitor code inti different files Possibly moving it to its own directory: - monitor/monitor.c: common code - monitor/hmp.c: human monitor - monitor/qmp.c: (guess what) 8. Make the QMP C API a real API Ie. do all cleanup needed to make it consumable, maybe even outside of QEMU 9. Conquer the world