From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43503) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bxVsv-0003ic-W7 for qemu-devel@nongnu.org; Fri, 21 Oct 2016 05:13:11 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bxVsr-0004DH-1j for qemu-devel@nongnu.org; Fri, 21 Oct 2016 05:13:05 -0400 Received: from mx1.redhat.com ([209.132.183.28]:41232) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1bxVsq-0004D8-SW for qemu-devel@nongnu.org; Fri, 21 Oct 2016 05:13:00 -0400 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 3D3579B0F6 for ; Fri, 21 Oct 2016 09:13:00 +0000 (UTC) From: Markus Armbruster References: <20161018140141.GF12728@redhat.com> <87wph4g44n.fsf@dusky.pond.sub.org> <20161019081210.GA2035@work-vm> <20161019084235.GE11194@redhat.com> <87twc8d60e.fsf@dusky.pond.sub.org> <20161019100552.GD2035@work-vm> <20161019101616.GL11194@redhat.com> <87a8e0bkl6.fsf@dusky.pond.sub.org> <20161019122158.GS11194@redhat.com> <20161019180616.GF2035@work-vm> <20161020083730.GC12145@redhat.com> <417509f7-1640-39ca-cf95-06494a0b8ce5@redhat.com> Date: Fri, 21 Oct 2016 11:12:58 +0200 In-Reply-To: <417509f7-1640-39ca-cf95-06494a0b8ce5@redhat.com> (Paolo Bonzini's message of "Thu, 20 Oct 2016 18:56:11 +0200") Message-ID: <87zilykqud.fsf@dusky.pond.sub.org> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Qemu-devel] chardev's and fd's in monitors List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: "Daniel P. Berrange" , "Dr. David Alan Gilbert" , qemu-devel@nongnu.org Paolo Bonzini writes: > On 20/10/2016 10:37, Daniel P. Berrange wrote: >> You have a problem of context - if you have multiple monitors, how do >> you know which to send the error back to if you're not in the event >> loop thread, and thus cur_mon is NULL. With Marc-Andre's series which >> allows proper async command processing it gets even harder, because >> there's potentially many outstanding commands associated with a monitor >> and you need to decide which the error should be given to. > > Why should it even consult the current monitor? Shouldn't errors go to > all HMP monitors when QEMU falls back to error_report? Maybe. Copying error_report() output to human monitors is a courtesy to users who fail to watch stderr. But what about QMP? I figure all we could do there is sending some "Uh, here's an error message that may or may not be related to anything you've been doing in this monitor, do with it what you want" event. Would that be useful? Also, when you got an HMP monitor and stderr on the same tty (or whatever), you'd want to suppress one of the two messages.