On 2011-12-15 14:33, 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. We are also talking about introducing new commands twice, which is a PITA. Also, peoples interest in HMP vs. QMP varies. Some focus on management usability, others on human-machine interaction. So you get suggestions for new command typical either for one, not for both. 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