[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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



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.

Stefan


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]