From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:50002) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RbBor-0001ch-KC for qemu-devel@nongnu.org; Thu, 15 Dec 2011 08:58:03 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RbBoq-00025V-7F for qemu-devel@nongnu.org; Thu, 15 Dec 2011 08:57:57 -0500 Received: from goliath.siemens.de ([192.35.17.28]:31204) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RbBop-00025A-T5 for qemu-devel@nongnu.org; Thu, 15 Dec 2011 08:57:56 -0500 Message-ID: <4EE9FCDF.3080307@siemens.com> Date: Thu, 15 Dec 2011 14:57:51 +0100 From: Jan Kiszka MIME-Version: 1.0 References: <4EE9F3B8.6000407@siemens.com> <4EE9F734.7050305@redhat.com> <4EE9F842.4070907@redhat.com> <4EE9F8A6.2060007@siemens.com> <4EE9FAE0.5030009@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] Transitioning from HMP to QMP for QEMU List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: Kevin Wolf , Lucas Meneghel Rodrigues , Anthony Liguori , "libvir-list@redhat.com" , qemu-devel , Luiz Capitulino , Adam Litke On 2011-12-15 14:53, Stefan Hajnoczi wrote: > On Thu, Dec 15, 2011 at 1:49 PM, Kevin Wolf 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 -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux