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

[Jan Kiszka <jan.kiszka@siemens.com>]

On 2011-12-15 14:53, Stefan Hajnoczi wrote:
> On Thu, Dec 15, 2011 at 1:49 PM, Kevin Wolf <kwolf@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.

Monitor pass-through via gdbstub requires text formatting on QEMU side.
We could start providing a python plugin for gdb at some point that does
the pretty printing on the client side, but moving over will be a
lengthy process as well.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux