Re: [Qemu-devel] [PATCH 01/25] QMP: Rename query handlers

[Luiz Capitulino]

On Tue, 7 Dec 2010 10:28:25 -0200
Miguel Di Ciurcio Filho <address@hidden> wrote:

> On Mon, Dec 6, 2010 at 4:23 PM, Luiz Capitulino <address@hidden> 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
> >  *
> >  * Make an asynchronous request for balloon info.  When the request 
> > completes
> >  * a QDict will be returned according to the following specification:
> > @@ -106,7 +106,7 @@ void monitor_print_balloon(Monitor *mon, const QObject 
> > *data)
> >  *   "major_page_faults": 142, "minor_page_faults": 239245,
> >  *   "free_mem": 1014185984, "total_mem": 1044668416 }
> >  */
> > -int do_info_balloon(Monitor *mon, MonitorCompletion cb, void *opaque)
> > +int qmp_query_balloon(Monitor *mon, MonitorCompletion cb, void *opaque)
> >  {
> 
> 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 sometimes
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.
   
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