From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:39827) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RbCfS-0004LF-Rh for qemu-devel@nongnu.org; Thu, 15 Dec 2011 09:52:24 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RbCfO-0005kN-Ex for qemu-devel@nongnu.org; Thu, 15 Dec 2011 09:52:18 -0500 Received: from mx1.redhat.com ([209.132.183.28]:39790) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RbCfO-0005kI-4g for qemu-devel@nongnu.org; Thu, 15 Dec 2011 09:52:14 -0500 Date: Thu, 15 Dec 2011 12:52:03 -0200 From: Luiz Capitulino Message-ID: <20111215125203.698b2c07@doriath> In-Reply-To: <4EE9FEF1.4080709@codemonkey.ws> References: <20111215115731.3ee45e4b@doriath> <4EE9FEF1.4080709@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII 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: Anthony Liguori Cc: Kevin Wolf , Stefan Hajnoczi , qemu-devel , libvir-list@redhat.com, Adam Litke On Thu, 15 Dec 2011 08:06:41 -0600 Anthony Liguori wrote: > On 12/15/2011 07:57 AM, Luiz Capitulino wrote: > > On Thu, 15 Dec 2011 13:02:40 +0000 > > Stefan Hajnoczi wrote: > > > >> What is the status of QEMU's transition from HMP to the QMP interface? > > > > Depends on what you consider the transition to be. > > > > For management tools the transition can be considered done already because we > > do not support HMP as a stable interface. > > > >> My current understanding is that QEMU provides new HMP commands for > >> humans, but HMP is being phased out as an API. > > > > It already did. > > > >> 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. > > > > Exactly. > > > >> 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. > > > > Maybe it's a matter of terminology, but I have the impression you're > > talking about two things here: > > > > 1. HMP will always exist, in the meaning that qemu will always provide > > a human interface. If we move it to a python script or some kind of > > external process, that's an implementation detail. > > > > This means that, if you're adding new functionality to qemu and it > > does make sense for humans to use it, then it should have a HMP > > version. > > > > 2. If you do add the HMP interface, that's for humans to consume and > > its output/semantics should make sense for humans, not for management tools. > > 3. All HMP commands will be implemented in terms of QMP commands (and only in > terms of QMP commands). Right. > There are still a lot of HMP commands that don't have an QMP analog. Luiz, it > might make sense to setup a wiki page which instructions on how to convert an > HMP command to a QMP command using QAPI. I wrote on how to write new QMP commands using the QAPI (docs/writing-qmp-commands.txt), going from there to a conversion shouldn't be difficult, but I can write a wiki page. Btw, counting with a series I haven't posted yet, we have less than 10 QMP commands left to be converted to the QAPI. I expect to start working on HMP conversions in January. > If we did that, we could probably get more folks involved in the conversion process. That would be wonderful. > > Regards, > > Anthony Liguori > > > > >> 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. > >> > >> Stefan > >> > > > > >