From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:54114) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R0xw2-0000Yw-TC for qemu-devel@nongnu.org; Tue, 06 Sep 2011 11:51:44 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R0xvt-0006I0-Ce for qemu-devel@nongnu.org; Tue, 06 Sep 2011 11:51:38 -0400 Received: from mail-gy0-f173.google.com ([209.85.160.173]:50631) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R0xvt-0006Hu-0D for qemu-devel@nongnu.org; Tue, 06 Sep 2011 11:51:29 -0400 Received: by gyd12 with SMTP id 12so4384725gyd.4 for ; Tue, 06 Sep 2011 08:51:28 -0700 (PDT) Message-ID: <4E66417E.6040308@codemonkey.ws> Date: Tue, 06 Sep 2011 10:51:26 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <20110906144828.GA20834@redhat.com> <4E66402C.2020900@siemens.com> In-Reply-To: <4E66402C.2020900@siemens.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 0/6] Device state visualization reloaded List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: Markus Armbruster , Anthony Liguori , Luiz Capitulino , qemu-devel , "Michael S. Tsirkin" On 09/06/2011 10:45 AM, Jan Kiszka wrote: > On 2011-09-06 16:48, Michael S. Tsirkin wrote: >> I'm afraid that won't be enough to stop people >> scripting this command - libvirt accessed >> HMP for years. >> >> On the other hand, no QMP command means e.g. >> libvirt users don't get any benefit from this. >> >> What I think will solve these problems, for both HMP and QMP, >> is an explicit 'debug_unstable' or 'debug_unsupported' command that will >> expose all kind of debugging functionality making it >> very explicit that it's an unsupported debugging utility. >> >> Proposed syntax: >> >> debug_unstable >> >> Example: >> >> debug_unstable device_show -all > > For HMP, this would needlessly complicate the user interface, nothing I > would support. People scripting things on top of HMP are generally doing > this on their own risk and cannot expect output stability. > > device_show is like info qtree: the output will naturally change as the > emulated hardware evolves, information is added/removed, or we simply > improve the layout. Recent changes on info network are an example for > the latter. Yeah, I'm not worried about stability. HMP commands that aren't exposed as QMP commands are inherently unstable and should not be scripted to. I'm still contemplating how we go about doing this. This series introduces a couple new concepts like QMP class hinting anonymous IDs. I'm concerned that we'll further complicate the need to support backwards compatibility. Would the command be useful if you couldn't address devices? If it just dumped the full machine state all at once? That would at least obviate the need to add anonymous IDs. Regards, Anthony Liguori > > Jan >