From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:34113) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RbBda-0002Sd-Qh for qemu-devel@nongnu.org; Thu, 15 Dec 2011 08:46:24 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RbBdZ-00083Q-Dg for qemu-devel@nongnu.org; Thu, 15 Dec 2011 08:46:18 -0500 Received: from mx1.redhat.com ([209.132.183.28]:13757) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RbBdZ-00083M-4H for qemu-devel@nongnu.org; Thu, 15 Dec 2011 08:46:17 -0500 Message-ID: <4EE9FAE0.5030009@redhat.com> Date: Thu, 15 Dec 2011 14:49:20 +0100 From: Kevin Wolf MIME-Version: 1.0 References: <4EE9F3B8.6000407@siemens.com> <4EE9F734.7050305@redhat.com> <4EE9F842.4070907@redhat.com> <4EE9F8A6.2060007@siemens.com> In-Reply-To: <4EE9F8A6.2060007@siemens.com> 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: Jan Kiszka Cc: Lucas Meneghel Rodrigues , Anthony Liguori , "libvir-list@redhat.com" , Stefan Hajnoczi , qemu-devel , Luiz Capitulino , Adam Litke 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? And yes, strong NACK for removing the functionality. Kevin