From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Lrwgr-0003PT-EY for qemu-devel@nongnu.org; Thu, 09 Apr 2009 12:01:21 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Lrwgl-0003NO-So for qemu-devel@nongnu.org; Thu, 09 Apr 2009 12:01:20 -0400 Received: from [199.232.76.173] (port=44403 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Lrwgl-0003NK-NT for qemu-devel@nongnu.org; Thu, 09 Apr 2009 12:01:15 -0400 Received: from mx2.redhat.com ([66.187.237.31]:39868) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Lrwgk-0004Sq-FK for qemu-devel@nongnu.org; Thu, 09 Apr 2009 12:01:15 -0400 Message-ID: <49DE1BC2.3080200@redhat.com> Date: Thu, 09 Apr 2009 19:01:06 +0300 From: Avi Kivity 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> <49DE18FE.30803@siemens.com> In-Reply-To: <49DE18FE.30803@siemens.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: Jan Kiszka Cc: libvir-list@redhat.com, Anthony Liguori , Gerd Hoffmann , Hollis Blanchard , qemu-devel@nongnu.org Jan Kiszka wrote: >> 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. > The management application will still think the device is plugged in, and things will break if it isn't. Of course if you asked for notification X on session Y, then event X should be delivered to session Y no matter how it originated (but not to session Z). > >>> 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. > Very well. I guess a human user can open another session for notifications, if they are so inclined. > >> 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. > Fair enough. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic.