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

On 2011-12-15 14:53, Stefan Hajnoczi wrote: > On Thu, Dec 15, 2011 at 1:49 PM, Kevin Wolf <kwolf(a)redhat.com&gt; 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