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

[Stefan Hajnoczi <stefanha@gmail.com>]

On Thu, Dec 15, 2011 at 1:57 PM, Luiz Capitulino <lcapitulino@redhat.com> 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.

This entire email is useful, thanks.  It feels like this should be
captured somewhere - on the wiki, in qemu/doc/, or as a comment in
monitor.c.  That way anyone who wishes to contribute new monitor
commands will start with the right idea.

Stefan