From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from szxga03-in.huawei.com ([119.145.14.66]) by bombadil.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1Y8JGv-0003JA-7K for linux-mtd@lists.infradead.org; Tue, 06 Jan 2015 01:49:26 +0000 Message-ID: <54AB3EEC.2080500@huawei.com> Date: Tue, 6 Jan 2015 09:48:28 +0800 From: hujianyang MIME-Version: 1.0 To: Joseph Balough Subject: Re: [PATCH 2/2] mtd: ubiformat: Add confirmation fail exit References: <1420037925-31156-1-git-send-email-jbb5044@gmail.com> <1420037925-31156-3-git-send-email-jbb5044@gmail.com> <54A8A7A1.8060802@huawei.com> In-Reply-To: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Cc: linux-mtd List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On 2015/1/5 23:07, Joseph Balough wrote: > > On Sat, Jan 3, 2015 at 9:38 PM, hujianyang > wrote: > > > There is not need to return different values for any error cases, and a > positive return value is not proper for a aborted case. > > Just print a error message at failure happening is enough, I think. > > > It was useful for me to know what the specific error was -- A messed up ubi file could indicate a bad download while a confirm error could indicate bad flash. It's no problem for me, I can just leave my patch as something I apply locally. I do wonder about the current exit value on error. ubiformat currently exits -1 when there is an error. The exit status for programs in UNIX are 8-bit unsigned integers, so the program actually exits 255. Perhaps this should at least return 1 instead of -1. The exit status for programs in UNIX are 8-bit unsigned integers, so the program actually exits 255. Perhaps this should at least return 1 instead of -1. Yes, you are right~! Sorry for it.