From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LrwVL-0005ZG-Ba for qemu-devel@nongnu.org; Thu, 09 Apr 2009 11:49:27 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LrwVG-0005SM-5P for qemu-devel@nongnu.org; Thu, 09 Apr 2009 11:49:26 -0400 Received: from [199.232.76.173] (port=55824 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LrwVF-0005Rs-T5 for qemu-devel@nongnu.org; Thu, 09 Apr 2009 11:49:21 -0400 Received: from lizzard.sbs.de ([194.138.37.39]:23230) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LrwVF-0002gW-Ca for qemu-devel@nongnu.org; Thu, 09 Apr 2009 11:49:21 -0400 Message-ID: <49DE18FE.30803@siemens.com> Date: Thu, 09 Apr 2009 17:49:18 +0200 From: Jan Kiszka MIME-Version: 1.0 Subject: Re: [libvirt] Re: [Qemu-devel] [PATCH 1/6] Allow multiple monitor devices (v2) References: <1239215702-23818-1-git-send-email-aliguori@us.ibm.com> <49DDAF9F.7040400@redhat.com> <49DDF807.1050707@us.ibm.com> <49DDFAD5.7060808@redhat.com> <49DDFC5C.4080504@us.ibm.com> <49DE0042.9050103@redhat.com> <49DE0303.7070507@redhat.com> <49DE03F0.6070503@redhat.com> <49DE0C98.5000402@siemens.com> <49DE1125.3080108@redhat.com> In-Reply-To: <49DE1125.3080108@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: libvir-list@redhat.com, Anthony Liguori , Gerd Hoffmann , Hollis Blanchard , qemu-devel@nongnu.org Avi Kivity wrote: > Jan Kiszka wrote: >> Avi Kivity wrote: >> >>> Gerd Hoffmann wrote: >>> >>>> On 04/09/09 16:03, Avi Kivity wrote: >>>> >>>>> I don't want multiplexed monitor sessions, at all. >>>>> >>>> I'm very happy to finally see them. Finally one can run vms with >>>> libvirt and *still* access the monitor for debugging and development >>>> purposes. >>>> >>>> >>> Right, I like them for that purpose as well. But not for ordinary >>> control. >>> >> >> How do you want to differentiate? What further complications would this >> bring us? >> > > I'm not sure I understand your questions. Multiple monitor sessions are > like multiple shell sessions. I don't think a control program should > use more than one session, but it should allow a developer to connect to > issue 'info registers' and 'x/20i' commands. Of course if a developer > issues 'quit' or a hotunplug command, things will break. We agree if we want decoupled states of the monitor sessions (one session should definitely not be used to configure the output of another one). But I see no issues with collecting the events in one session that happen to be caused by activity in some other session. But maybe I'm missing your point. >> >> Please no more async notifications to the monitors. They are just ugly >> to parse, at least for us humans. I don't want to see any notification >> in the middle of my half-typed command e.g. >> > > If we can identify an interactive session, we might redraw the partial > command after the prompt. Uhh, please not this kind of terminal reprinting. The terminal user keep full control over when things can be printed. > > btw, why would a human enable notifications? Note notifications enabled > on the management session will only be displayed there. It's true that the common use case for events will be monitor applications. Still, enabling them for testing or simple scripting should not switch on ugly output mode or complicate the parsing. Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux