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&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.