Re: [libvirt] [Qemu-devel] Transitioning from HMP to QMP for QEMU
On Thu, Dec 15, 2011 at 1:49 PM, Kevin Wolf <kwolf(a)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 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.
Stefan