From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57467) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1btwWT-0001Fi-7R for qemu-devel@nongnu.org; Tue, 11 Oct 2016 08:51:10 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1btwWO-0001xo-BH for qemu-devel@nongnu.org; Tue, 11 Oct 2016 08:51:08 -0400 Received: from mx1.redhat.com ([209.132.183.28]:50438) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1btwWO-0001xf-51 for qemu-devel@nongnu.org; Tue, 11 Oct 2016 08:51:04 -0400 Date: Tue, 11 Oct 2016 20:51:01 +0800 From: Fam Zheng Message-ID: <20161011125101.GG5814@lemon> References: <20160926162846.GL18393@redhat.com> <20160929024530.GC6412@lemon> <874m4xmi29.fsf@dusky.pond.sub.org> <20161001121043.GA26716@lemon> <87k2doimqu.fsf@dusky.pond.sub.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87k2doimqu.fsf@dusky.pond.sub.org> Subject: Re: [Qemu-devel] top(1) utility implementation in QEMU List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: prashanth sunder , qemu-devel@nongnu.org On Tue, 10/04 09:42, Markus Armbruster wrote: > >> What's the advantage over simply using another QMP monitor? Naturally, > >> injecting arbitrary QMP commands behind libvirt's back isn't going to > >> end well, but "don't do that then". Information queries and listening > >> to events should be safe. > > > > In order to avoid a Libvirt "tainted" state at production env, of course > > assuming qemu-top is useful there at all. > > Adding another QMP-like protocol seems like a rather steep price just > for avoiding "tainted". > > Any chance we can provide this feature together with libvirt instead of > behind its back? That would be the best, but I am not sure how to make an appropriate interface. > > >> Note that we could have a QMP command to spawn monitors. Fun! > > > > Cool, and how hard is it to implement a QMP command to kill monitors? :) > > For spawning, we need to adapt the current spawn code to work after > initial startup, too. For killing, we need to write new code. Might be > harder, but can't say until we try. > Fam