From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49130) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bxh1R-0000os-1o for qemu-devel@nongnu.org; Fri, 21 Oct 2016 17:06:38 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bxh1N-0006a3-2x for qemu-devel@nongnu.org; Fri, 21 Oct 2016 17:06:37 -0400 Received: from mail-wm0-x22d.google.com ([2a00:1450:400c:c09::22d]:38152) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1bxh1M-0006Zv-T2 for qemu-devel@nongnu.org; Fri, 21 Oct 2016 17:06:33 -0400 Received: by mail-wm0-x22d.google.com with SMTP id c78so7115064wme.1 for ; Fri, 21 Oct 2016 14:06:32 -0700 (PDT) Sender: Paolo Bonzini 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> <87zilykqud.fsf@dusky.pond.sub.org> From: Paolo Bonzini Message-ID: Date: Fri, 21 Oct 2016 23:06:29 +0200 MIME-Version: 1.0 In-Reply-To: <87zilykqud.fsf@dusky.pond.sub.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] chardev's and fd's in monitors List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: "Dr. David Alan Gilbert" , qemu-devel@nongnu.org On 21/10/2016 11:12, Markus Armbruster wrote: > 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. If you have an HMP monitor you wouldn't print to stderr---stderr would be reserved for the case where there are only QMP monitors. Paolo