From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LWYKD-0003ps-AJ for qemu-devel@nongnu.org; Mon, 09 Feb 2009 10:45:33 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LWYKB-0003ox-N4 for qemu-devel@nongnu.org; Mon, 09 Feb 2009 10:45:32 -0500 Received: from [199.232.76.173] (port=58343 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LWYKB-0003oq-I6 for qemu-devel@nongnu.org; Mon, 09 Feb 2009 10:45:31 -0500 Received: from lizzard.sbs.de ([194.138.37.39]:24592) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LWYKB-0004bn-20 for qemu-devel@nongnu.org; Mon, 09 Feb 2009 10:45:31 -0500 Received: from mail2.sbs.de (localhost [127.0.0.1]) by lizzard.sbs.de (8.12.11.20060308/8.12.11) with ESMTP id n19FjSvx001353 for ; Mon, 9 Feb 2009 16:45:28 +0100 Received: from [139.25.109.167] (mchn012c.ww002.siemens.net [139.25.109.167] (may be forged)) by mail2.sbs.de (8.12.11.20060308/8.12.11) with ESMTP id n19FjSFg029415 for ; Mon, 9 Feb 2009 16:45:28 +0100 Message-ID: <49904F98.4030509@siemens.com> Date: Mon, 09 Feb 2009 16:45:28 +0100 From: Jan Kiszka MIME-Version: 1.0 References: <20090207181627.13667.9979.stgit@mchn012c.ww002.siemens.net> <20090207181629.13667.20945.stgit@mchn012c.ww002.siemens.net> <499048C4.3030603@us.ibm.com> In-Reply-To: <499048C4.3030603@us.ibm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [PATCH 14/17] monitor: Decouple terminals Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Anthony Liguori wrote: > Jan Kiszka wrote: >> Currently all registered (and activate) monitor terminals work in >> broadcast mode: Everyone sees what someone else types on some other >> terminal and what the monitor reports back. This model is broken when >> you have a management monitor terminal that is automatically operated >> and some other terminal used for independent guest inspection. Such an >> additional terminal can be a multiplexed device channel or a gdb >> frontend connected to QEMU's stub. >> >> Therefor, this patch decouples the buffers and states of all monitor >> terminals, allowing the user to operate them independently. The basic >> idea is stolen from Jason Wessel: When starting to handle a monitor >> command or some terminal event, the current monitor terminal is set to >> the one associated with the underlying char device, letting all >> succeeding monitor_printf show up on only this selected terminal. >> >> There are still two asynchronous monitor writers: some error reporting >> in VNC's audio_add and the log-to-monitor feature of the audio >> subsystem. > > That concerns me. Nothing should output to the monitor asychronously. Indeed. > > I'd like to see a few changes to make things a bit closer to the long > term goals for the monitor (having proper multiple monitors devoid of > global state). > > Here's what I'd suggest: > > 1) Make monitor_printf() take a monitor state. The easiest thing to do > would be to introduce this in your previous rename patch making > everything use current_monitor. Lazy /me was hoping to get around this... > 2) Introduce current_monitor and default_monitor global variables. They > map to what you describe above and should be maintained as such. > 3) Make all monitor callbacks take a monitor state > 4) Convert monitor_printf()s called from monitor callbacks to use the > passed monitor state > 5) Eliminate all uses of current_monitor/default_monitor. > > I'd say, 1 and 2 are required for this patchset. I think 3 and 4 would > be pretty easy to add to your patchset. I think 5 is probably tougher > and could wait for another day. My feeling is (though I have not sound stats at hand) that a lot of functions all over the place will have to be extended in order to pass the target monitor around: From the command callbacks, through all the subsystems, finally reaching the monitor API. Some use cases only consist of the command callback itself, OK, but the others worry me a bit. All doable, for sure, but I just want to make sure that we all agree on the result before starting this "tough" endeavor. :) Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux