[libvirt] [Qemu-devel] Transitioning from HMP to QMP for QEMU
Luiz Capitulino
lcapitulino at redhat.com
Thu Dec 15 14:52:03 UTC 2011
On Thu, 15 Dec 2011 08:06:41 -0600
Anthony Liguori <anthony at 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 at 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
> >>
> >
> >
>
More information about the libvir-list
mailing list