From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=60950 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OHzsX-0002m9-DU for qemu-devel@nongnu.org; Fri, 28 May 2010 09:45:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OHzsR-0001uv-8C for qemu-devel@nongnu.org; Fri, 28 May 2010 09:45:35 -0400 Received: from mx1.redhat.com ([209.132.183.28]:13577) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OHzsR-0001up-1e for qemu-devel@nongnu.org; Fri, 28 May 2010 09:45:31 -0400 Date: Fri, 28 May 2010 10:45:16 -0300 From: Luiz Capitulino Message-ID: <20100528104516.1d81ba4f@redhat.com> In-Reply-To: <4BFEF018.9000705@web.de> References: <5d0139dc62706a1efcbb6a63d5936484ad279916.1274612367.git.jan.kiszka@web.de> <20100527173147.304ee68b@redhat.com> <4BFEF018.9000705@web.de> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [PATCH v3 13/17] monitor: Allow to exclude commands from QMP List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: Anthony Liguori , Juan Quintela , Markus@gnu.org, qemu-devel@nongnu.org, Armbruster , Blue Swirl , Avi Kivity , Jan Kiszka On Fri, 28 May 2010 00:20:08 +0200 Jan Kiszka wrote: > Luiz Capitulino wrote: > > On Sun, 23 May 2010 12:59:26 +0200 > > Jan Kiszka wrote: > > > >> From: Jan Kiszka > >> > >> Ported commands that are marked 'user_only' will not be considered for > >> QMP monitor sessions. This allows to implement new commands that do not > >> (yet) provide a sufficiently stable interface for QMP use (e.g. > >> device_show). > > > > This is fine for me, but two things I've been wondering: > > > > 1. Isn't a 'flags' struct member better? So that we can do (in the > > qemu-monitor.hx entry): > > > > .flags = MONITOR_USER_ONLY | MONITOR_HANDLER_ASYNC, > > > > I'm not suggesting this is an async handler, just exemplifying multiple > > flags. > > Yes, can refactor this. > > > > > 2. Getting QMP handlers right in the first time might be difficult, so > > we could have a way to mark them unstable. Maybe a different namespace > > which is only enabled at configure time with: > > > > --enable-qmp-unstable-commands > > > > If this were possible, we could have device_show and any command we > > aren't sure is QMP-ready working in QMP this way. > > Do you suggest this as an alternative to this patch? Or an extension > later on? I have no opinion on this yet, I would just like to know how > to proceed for this series. Both can be done worked later, as this is internal there's no problem in living with a simpler solution for a while.