From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37149) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bwpsk-0006Sy-0I for qemu-devel@nongnu.org; Wed, 19 Oct 2016 08:22:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bwpsg-0003A6-S1 for qemu-devel@nongnu.org; Wed, 19 Oct 2016 08:22:06 -0400 Received: from mx1.redhat.com ([209.132.183.28]:35782) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1bwpsg-00039p-Ma for qemu-devel@nongnu.org; Wed, 19 Oct 2016 08:22:02 -0400 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (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 0AC0780088 for ; Wed, 19 Oct 2016 12:22:02 +0000 (UTC) Date: Wed, 19 Oct 2016 13:21:58 +0100 From: "Daniel P. Berrange" Message-ID: <20161019122158.GS11194@redhat.com> Reply-To: "Daniel P. Berrange" References: <20161018133528.GD12728@redhat.com> <20161018135213.GI2190@work-vm> <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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <87a8e0bkl6.fsf@dusky.pond.sub.org> 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 Wed, Oct 19, 2016 at 02:16:05PM +0200, Markus Armbruster wrote: > "Daniel P. Berrange" writes: > > > On Wed, Oct 19, 2016 at 11:05:53AM +0100, Dr. David Alan Gilbert wrote: > >> > >> We need a way to be able to report an error without plumbing error_setg > >> up the stack; if you're saying error_report isn't suitable then we > >> should just recommend we switch everything in migration back to > >> fprintf(stderr, > > In the cases where error_report() isn't suitable, fprintf() is just as > unsuitable for the exact same reasons. > > > Well both error_report() + fprintf are broken from POV of anything > > using QMP. error_report() is slightly less broken for HMP, > > error_report() is not broken at all for HMP code. The trouble is code > that can't know whether it's running in a context where error_report() > is suitable. > > > but doesn't > > help QMP. > > Correct. > > > In the short term we should just make error_report be threadsafe in > > its usage of the monitor. > > Any problems left once cur_mon is thread-local (which it should be > anyway)? If we make cur_mon a thread-local, then error_report() is equivalent to fprintf(stderr) for the migration code, since the migration code runs in a different thread thread, and so would always see cur_mon == NULL. > > Beyond the short term we have no choice but > > to plumb in error_setg throughout, otherwise QMP will continue to > > have useless error reporting in this area of code. > > Actually, no choice but propagate errors up the stack until they reach a > spot that knows how to report them. error_setg() is *one* way to do > that. Its prime advantage is ability to carry an error message. Its > disadvantage is boilerplate. Use it as needed. Just don't convert back > and forth between Error and other representations while propagating up > the stack. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://entangle-photo.org -o- http://search.cpan.org/~danberr/ :|