From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:33378) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RJKzj-0005Z4-Ev for qemu-devel@nongnu.org; Thu, 27 Oct 2011 04:07:24 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RJKzi-0007Ec-GB for qemu-devel@nongnu.org; Thu, 27 Oct 2011 04:07:23 -0400 Received: from e28smtp09.in.ibm.com ([122.248.162.9]:49841) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RJKzh-0007EV-PE for qemu-devel@nongnu.org; Thu, 27 Oct 2011 04:07:22 -0400 Received: from /spool/local by e28smtp09.in.ibm.com with XMail ESMTP for from ; Thu, 27 Oct 2011 13:37:16 +0530 Received: from d28av01.in.ibm.com (d28av01.in.ibm.com [9.184.220.63]) by d28relay01.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p9R87EQ64366580 for ; Thu, 27 Oct 2011 13:37:14 +0530 Received: from d28av01.in.ibm.com (loopback [127.0.0.1]) by d28av01.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p9R87E3c021094 for ; Thu, 27 Oct 2011 13:37:14 +0530 Message-ID: <4EA910E5.9080909@linux.vnet.ibm.com> Date: Thu, 27 Oct 2011 16:05:57 +0800 From: "Cao,Bing Bu" MIME-Version: 1.0 References: <4EA8F73E.9010607@linux.vnet.ibm.com> In-Reply-To: <4EA8F73E.9010607@linux.vnet.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] Abnormal function exit message in Qemu block drivers code List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: shu ming Cc: QEMU Developers On 10/27/2011 02:16 PM, shu ming wrote: > Hi, > After reading the block driver code in, it was found that the error > exit code behaved in different ways. Here are some examples. It > seems that way 3 is a better way to log the error message. In fact, > It is pretty important for a administrator to know what is going on > and be informed the error when that happens. I believe we should > convert all the error exit code to way 3 gradually and make all the > new code to follow an unique standard. > Further more, really, some errors can be ignored while others can > not. So we can have a more flexible function to classify the level of > the error message like > error_report(log_level, "string format", string); > > 1)The error code exited silently. > > case QCOW2_EXT_MAGIC_BACKING_FORMAT: > if (ext.len >= sizeof(bs->backing_format)) { > fprintf(stderr, "ERROR: ext_backing_format: len=%u too > large" > " (>=%zu)\n", > ext.len, sizeof(bs->backing_format)); > return 2; > } The example of the first way looks like not correct. case QCOW2_EXT_MAGIC_BACKING_FORMAT: if (ext.len >= sizeof(bs->backing_format)) { - fprintf(stderr, "ERROR: ext_backing_format: len=%u too large" - " (>=%zu)\n", - ext.len, sizeof(bs->backing_format)); return 2; } > 2) fprintf() to emit the error message > > case QCOW2_EXT_MAGIC_BACKING_FORMAT: > if (ext.len >= sizeof(bs->backing_format)) { > fprintf(stderr, "ERROR: ext_backing_format: len=%u too > large" > " (>=%zu)\n", > ext.len, sizeof(bs->backing_format)); > return 2; > 3) A error_report() function to emit the error message. > > /* Find driver and parse its options */ > drv = bdrv_find_format(fmt); > if (!drv) { > error_report("Unknown file format '%s'", fmt); > ret = -EINVAL; > goto out; > } > > >