From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57697) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bZvMD-0004Aw-3z for qemu-devel@nongnu.org; Wed, 17 Aug 2016 03:33:50 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bZvM5-0003ps-ML for qemu-devel@nongnu.org; Wed, 17 Aug 2016 03:33:48 -0400 Received: from mx1.redhat.com ([209.132.183.28]:42762) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bZvM5-0003pl-Hd for qemu-devel@nongnu.org; Wed, 17 Aug 2016 03:33:41 -0400 From: Markus Armbruster References: <1470901038-9409-1-git-send-email-peterx@redhat.com> <1470901038-9409-2-git-send-email-peterx@redhat.com> <87eg5p6kk0.fsf@dusky.pond.sub.org> <20160816115351.GB27853@al.usersys.redhat.com> <20160816121708.GD9866@pxdev.xzpeter.org> <20160816121908.GA28518@al.usersys.redhat.com> <20160816140018.GG9866@pxdev.xzpeter.org> <87zioc22o6.fsf@dusky.pond.sub.org> <20160817064726.GB14217@pxdev.xzpeter.org> Date: Wed, 17 Aug 2016 09:33:37 +0200 In-Reply-To: <20160817064726.GB14217@pxdev.xzpeter.org> (Peter Xu's message of "Wed, 17 Aug 2016 14:47:26 +0800") Message-ID: <87ziobsvce.fsf@dusky.pond.sub.org> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Qemu-devel] [PATCH 1/2] error-report: provide error_report_exit() List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Xu Cc: peter.maydell@linaro.org, Fam Zheng , qemu-devel@nongnu.org, pbonzini@redhat.com Peter Xu writes: > On Tue, Aug 16, 2016 at 04:45:13PM +0200, Markus Armbruster wrote: >> Peter Xu writes: >> >> > On Tue, Aug 16, 2016 at 08:19:08PM +0800, Fam Zheng wrote: >> >> On Tue, 08/16 20:17, Peter Xu wrote: >> >> > > Do we really need error_report_exit when we already have error_fatal? >> >> > >> >> > error_fatal is the name of a global var, not the function. >> >> >> >> I mean most error_report_exit(...) calls can be converted to >> >> error_setg(&error_fatal, ...). >> > >> > Right. But it's just another way to implement error_report_fatal(). We >> > may still need error_report_fatal() since it's cleaner and shorter >> > than error_setg(&error_fatal, ...). >> >> Fam's point that >> >> error_report_fatal(...); >> >> is just another way to write >> >> error_setg(&error_fatal, ...) >> >> is valid. Your point that the former is shorter and simpler is also >> valid. In fact, error.h advises: >> >> * Please don't error_setg(&error_fatal, ...), use error_report() and >> * exit(), because that's more obvious. >> * Likewise, don't error_setg(&error_abort, ...), use assert(). >> >> Could you convert the existing error_setg(&error_fatal, ...) to >> error_report_fatal(...)? >> >> Regarding error_report_abort(): in my opinion, printing pretty messages >> right before abort() is largely a waste of time. But if people insist >> on doing it, then the error subsystem may have to support it. Would you >> be willing to track down such usage, so we can make an informed >> decision? > > Sure. :) > > Yes I see usages for error_setg(&error_abort, ...), it makes sense to > provide error_report_abort() along with error_report_fatal(). Will > take your (and Fam's) advice. Recommend to make it a separate patch. > Thanks for your comments! You're welcome!