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

[Luiz Capitulino <lcapitulino@redhat.com>]

On Thu, 15 Dec 2011 08:06:41 -0600
Anthony Liguori <anthony@codemonkey.ws> wrote:

> On 12/15/2011 07:57 AM, Luiz Capitulino wrote:
> > On Thu, 15 Dec 2011 13:02:40 +0000
> > Stefan Hajnoczi<stefanha@gmail.com>  wrote:
> >
> >> What is the status of QEMU's transition from HMP to the QMP interface?
> >
> > Depends on what you consider the transition to be.
> >
> > For management tools the transition can be considered done already because we
> > do not support HMP as a stable interface.
> >
> >> My current understanding is that QEMU provides new HMP commands for
> >> humans, but HMP is being phased out as an API.
> >
> > It already did.
> >
> >>   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.
> >
> > Exactly.
> >
> >> 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.
> >
> > Maybe it's a matter of terminology, but I have the impression you're
> > talking about two things here:
> >
> >   1. HMP will always exist, in the meaning that qemu will always provide
> >      a human interface. If we move it to a python script or some kind of
> >      external process, that's an implementation detail.
> >
> >      This means that, if you're adding new functionality to qemu and it
> >      does make sense for humans to use it, then it should have a HMP
> >      version.
> >
> >   2. If you do add the HMP interface, that's for humans to consume and
> >      its output/semantics should make sense for humans, not for management tools.
> 
> 3. All HMP commands will be implemented in terms of QMP commands (and only in 
> terms of QMP commands).

Right.

> There are still a lot of HMP commands that don't have an QMP analog.  Luiz, it 
> might make sense to setup a wiki page which instructions on how to convert an 
> HMP command to a QMP command using QAPI.

I wrote on how to write new QMP commands using the QAPI
(docs/writing-qmp-commands.txt), going from there to a conversion shouldn't
be difficult, but I can write a wiki page.

Btw, counting with a series I haven't posted yet, we have less than 10 QMP
commands left to be converted to the QAPI. I expect to start working on HMP
conversions in January.

> If we did that, we could probably get more folks involved in the conversion process.

That would be wonderful.

> 
> Regards,
> 
> Anthony Liguori
> 
> >
> >> 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.
> >>
> >> Stefan
> >>
> >
> >
>