From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:37549)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <peterx@redhat.com>) id 1bhaJF-00088f-QR
	for qemu-devel@nongnu.org; Wed, 07 Sep 2016 06:42:26 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <peterx@redhat.com>) id 1bhaJA-0007oV-SC
	for qemu-devel@nongnu.org; Wed, 07 Sep 2016 06:42:24 -0400
Received: from mx1.redhat.com ([209.132.183.28]:43292)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <peterx@redhat.com>) id 1bhaJA-0007oL-NR
	for qemu-devel@nongnu.org; Wed, 07 Sep 2016 06:42:20 -0400
Date: Wed, 7 Sep 2016 18:42:14 +0800
From: Peter Xu <peterx@redhat.com>
Message-ID: <20160907104214.GA28348@pxdev.xzpeter.org>
References: <1473228390-18669-1-git-send-email-peterx@redhat.com>
	<87bn00ysg0.fsf@linaro.org> <20160907093308.GA5775@lemon>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20160907093308.GA5775@lemon>
Content-Transfer-Encoding: quoted-printable
Subject: Re: [Qemu-devel] [PATCH v4 0/4] Introduce error_report_{fatal|abort}
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel/>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Fam Zheng <famz@redhat.com>
Cc: Alex =?utf-8?Q?Benn=C3=A9e?= <alex.bennee@linaro.org>, qemu-devel@nongnu.org, peter.maydell@linaro.org, armbru@redhat.com, pbonzini@redhat.com

On Wed, Sep 07, 2016 at 05:33:08PM +0800, Fam Zheng wrote:
> On Wed, 09/07 10:23, Alex Benn=C3=A9e wrote:
> > Last time I needed to do error reporting I was told the error_setg
> > method was the correct way to do it and the report/exit case made sen=
se
> > only in the top level. Before we add even more error reporting
> > primitives can we update HACKING (or possibly add somethings to docs/=
)
> > that describes when and where the various error report mechanisms sho=
uld
> > be used?
>=20
> FWIW, the comment of error_setg clarifies the recommended usage now:
>=20
> ...
> >  * 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().
> >  */
> > #define error_setg(errp, fmt, ...)                              \

I can update both HACKING and above comment to mention about the new
interface in v5 (if we will have a v5) by appending a new patch for
the docs. Otherwise, I can post the patch seperately when needed.

Thanks,

-- peterx