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

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

 



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.

Jan

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

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list


[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]