On Thu, 15 Dec 2011 14:57:51 +0100 Jan Kiszka <jan.kis...@siemens.com> wrote:
> On 2011-12-15 14:53, Stefan Hajnoczi wrote: > > On Thu, Dec 15, 2011 at 1:49 PM, Kevin Wolf <kw...@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, if you look at hmp.c you'll see that HMP is using QMP as a client. Of course that there are a lot of commands to be converted, but it's just a matter of time to get this done. > > > > 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. Yes, I expect some HMP commands to be difficult to port and that will require time. But if anyone is interested, we could start making qmp-shell a decent shell as Stefan suggests above. In the beginning it won't have all commands HMP has today, but in the future it could replace it. > > Jan >
