From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:39071) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QzXWd-0006Rw-Kk for qemu-devel@nongnu.org; Fri, 02 Sep 2011 13:27:35 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QzXWc-0000R9-8g for qemu-devel@nongnu.org; Fri, 02 Sep 2011 13:27:31 -0400 Received: from mx1.redhat.com ([209.132.183.28]:58686) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QzXWc-0000Qv-1g for qemu-devel@nongnu.org; Fri, 02 Sep 2011 13:27:30 -0400 Date: Fri, 2 Sep 2011 14:27:26 -0300 From: Luiz Capitulino Message-ID: <20110902142726.4839f5d6@doriath> In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII 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: Anthony Liguori , qemu-devel , Markus Armbruster On Fri, 26 Aug 2011 16:48:10 +0200 Jan Kiszka wrote: > More than one year ago I posted some patches to add a monitor command > callend device_show. The purpose of that command is to dump the state of > some qdev device based on its vmstate. > > To improve the usability of that interface, the previous series also > tried to create a canonical qdev tree path name format and even added > monitor command expansion. That format created quite a few discussions, > and we never came to some conclusion. > > As device_show is still a useful tool for debugging but qdev structuring > and addressing may significantly change in the near future, I decided to > reanimate those patches while avoiding almost any change of the > addressing scheme. The only one I propose is automatic ID assignment for > anonymous devices so that any qdev device is in principle addressable > (e.g. APIC and IO-APIC on x86). > > As back then, device_show remains HMP-only to avoid any stable ABI > issues around QMP. > > CC: Luiz Capitulino > CC: Markus Armbruster This looks good to me and I'm willing to apply it. Only issue I'd like to see resolved is the base64 encoder/decoder. This series introduces a new one, while the guest agent uses glib's. I think we should choose one of them and stick to it. Any other objections apart from that? Markus?