[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Transitioning from HMP to QMP for QEMU
From: |
Luiz Capitulino |
Subject: |
Re: [Qemu-devel] Transitioning from HMP to QMP for QEMU |
Date: |
Thu, 15 Dec 2011 12:52:03 -0200 |
On Thu, 15 Dec 2011 08:06:41 -0600
Anthony Liguori <address@hidden> wrote:
> On 12/15/2011 07:57 AM, Luiz Capitulino wrote:
> > On Thu, 15 Dec 2011 13:02:40 +0000
> > Stefan Hajnoczi<address@hidden> 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
> >>
> >
> >
>
- Re: [Qemu-devel] Transitioning from HMP to QMP for QEMU, (continued)
- Re: [Qemu-devel] Transitioning from HMP to QMP for QEMU, Lucas Meneghel Rodrigues, 2011/12/15
- Re: [Qemu-devel] Transitioning from HMP to QMP for QEMU, Jan Kiszka, 2011/12/15
- Re: [Qemu-devel] Transitioning from HMP to QMP for QEMU, Stefan Hajnoczi, 2011/12/15
- Re: [Qemu-devel] Transitioning from HMP to QMP for QEMU, Kevin Wolf, 2011/12/15
- Re: [Qemu-devel] Transitioning from HMP to QMP for QEMU, Stefan Hajnoczi, 2011/12/15
- Re: [Qemu-devel] Transitioning from HMP to QMP for QEMU, Jan Kiszka, 2011/12/15
- Re: [Qemu-devel] Transitioning from HMP to QMP for QEMU, Luiz Capitulino, 2011/12/15
Re: [Qemu-devel] [libvirt] Transitioning from HMP to QMP for QEMU, Stefan Berger, 2011/12/15
Re: [Qemu-devel] Transitioning from HMP to QMP for QEMU, Luiz Capitulino, 2011/12/15
Re: [Qemu-devel] Transitioning from HMP to QMP for QEMU, Stefan Hajnoczi, 2011/12/15