[libvirt] [Qemu-devel] Transitioning from HMP to QMP for QEMU

[Luiz Capitulino]

On Thu, 15 Dec 2011 14:57:51 +0100
Jan Kiszka <jan.kiszka at siemens.com> wrote:

> On 2011-12-15 14:53, Stefan Hajnoczi wrote:
> > On Thu, Dec 15, 2011 at 1:49 PM, Kevin Wolf <kwolf at redhat.com> wrote:
> >> Am 15.12.2011 14:39, schrieb Jan Kiszka:
> >>> On 2011-12-15 14:38, Lucas Meneghel Rodrigues wrote:
> >>>> On 12/15/2011 11:33 AM, Kevin Wolf wrote:
> >>>>> Am 15.12.2011 14:18, schrieb Jan Kiszka:
> >>>>>> On 2011-12-15 14:02, Stefan Hajnoczi wrote:
> >>>>>>> What is the status of QEMU's transition from HMP to the QMP interface?
> >>>>>>>
> >>>>>>> My current understanding is that QEMU provides new HMP commands for
> >>>>>>> humans, but HMP is being phased out as an API.  Management tools
> >>>>>>> should rely only on QMP for new commands.  That would mean new HMP
> >>>>>>> commands are not guaranteed to produce backwards-compatible output
> >>>>>>> because tools are not supposed to parse the output.
> >>>>>>>
> >>>>>>> On the libvirt side, new QEMU features should only be supported via
> >>>>>>> the json monitor in the future (i.e. human monitor patches should not
> >>>>>>> be sent/merged)?  Existing HMP commands will still need the human
> >>>>>>> monitor support in order to handle old QEMU versions gracefully, but
> >>>>>>> I'm thinking about new commands only.
> >>>>>>>
> >>>>>>> Does everyone agree on this?  I think this is an important discussion
> >>>>>>> if we want our management interface to get better and more consistent
> >>>>>>> in the future.
> >>>>>>
> >>>>>> To phase out the classic HMP implementation, we need an internal
> >>>>>> HMP-over-JSON wrapper (with tab expansion etc.) so that virtual console
> >>>>>> and gdbstub monitors continue to benefit from new commands. Those
> >>>>>> interfaces will stay for a long time, I'm sure.
> >>>>>
> >>>>> I think we're not talking about dropping HMP here, only about how long
> >>>>> to support it as a stable API for management tools. I believe that we
> >>>>> have been in a transitional phase for long enough now that we can start
> >>>>> changing the output format of HMP commands without considering it an API
> >>>>> breakage.
> >>>>
> >>>> Yes, I've got the same impression. But while we are at it, forgive my
> >>>> naiveness, but wouldn't be worthwhile to consider dropping the human
> >>>> monitor in the long run?
> >>>
> >>> Surely not the interface (for virtual console & gdbstub), but the
> >>> internal implementation I hope.
> >>
> >> Isn't HMP implemented in terms of QMP these days?

Yes, if you look at hmp.c you'll see that HMP is using QMP as a client. Of
course that there are a lot of commands to be converted, but it's just a
matter of time to get this done.

> > 
> > Yes and no, I don't mean writing text manipulation code on to of QMP
> > command handlers the way we're doing now.  It's a pain.
> > 
> > I meant more along the lines of making qmp-shell more human-friendly.
> > You already can specify the command in a command-line fashion - you
> > don't need to write raw JSON.  I think it's a question of improving
> > this and perhaps integrating the documentation for the QMP/QAPI
> > commands right at the prompt so that it's easy to learn about the
> > available commands.  This would be a new interactive shell that stays
> > much closer to QMP so that we don't bother with maintaining
> > per-command text formatting functions like we do with HMP today.
> 
> Monitor pass-through via gdbstub requires text formatting on QEMU side.
> We could start providing a python plugin for gdb at some point that does
> the pretty printing on the client side, but moving over will be a
> lengthy process as well.

Yes, I expect some HMP commands to be difficult to port and that will
require time. But if anyone is interested, we could start making qmp-shell
a decent shell as Stefan suggests above. In the beginning it won't have
all commands HMP has today, but in the future it could replace it.

> 
> Jan
>