From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:46478) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RJJHV-00051M-Qd for qemu-devel@nongnu.org; Thu, 27 Oct 2011 02:17:38 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RJJHU-0004mY-Mv for qemu-devel@nongnu.org; Thu, 27 Oct 2011 02:17:37 -0400 Received: from e23smtp04.au.ibm.com ([202.81.31.146]:34845) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RJJHT-0004mT-Sb for qemu-devel@nongnu.org; Thu, 27 Oct 2011 02:17:36 -0400 Received: from d23relay04.au.ibm.com (d23relay04.au.ibm.com [202.81.31.246]) by e23smtp04.au.ibm.com (8.14.4/8.13.1) with ESMTP id p9R6AZVp006086 for ; Thu, 27 Oct 2011 17:10:35 +1100 Received: from d23av04.au.ibm.com (d23av04.au.ibm.com [9.190.235.139]) by d23relay04.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p9R6EhuN610344 for ; Thu, 27 Oct 2011 17:14:45 +1100 Received: from d23av04.au.ibm.com (loopback [127.0.0.1]) by d23av04.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p9R6HOfx026821 for ; Thu, 27 Oct 2011 17:17:24 +1100 Received: from [127.0.0.1] ([9.115.122.39]) by d23av04.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p9R6HMml025640 for ; Thu, 27 Oct 2011 17:17:23 +1100 Message-ID: <4EA8F73E.9010607@linux.vnet.ibm.com> Date: Thu, 27 Oct 2011 14:16:30 +0800 From: shu ming MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Abnormal function exit message in Qemu block drivers code List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: QEMU Developers 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; } 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; }