From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-bw0-f49.google.com ([209.85.214.49]) by bombadil.infradead.org with esmtp (Exim 4.72 #1 (Red Hat Linux)) id 1OyJXK-00060B-FQ for linux-mtd@lists.infradead.org; Wed, 22 Sep 2010 07:14:39 +0000 Received: by bwz19 with SMTP id 19so340719bwz.36 for ; Wed, 22 Sep 2010 00:14:36 -0700 (PDT) Subject: Re: [PATCH] nandwrite: add --nobad to write bad blocks From: Artem Bityutskiy To: Mike Frysinger In-Reply-To: References: <1284263480-31573-1-git-send-email-vapier@gentoo.org> <1284308851.1783.23.camel@brekeke> <1284358990.27765.154.camel@localhost> <1284441967.2084.18.camel@brekeke> Content-Type: text/plain; charset="UTF-8" Date: Wed, 22 Sep 2010 10:12:50 +0300 Message-ID: <1285139570.7512.137.camel@localhost> Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Cc: linux-mtd@lists.infradead.org Reply-To: dedekind1@gmail.com List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Wed, 2010-09-22 at 00:23 -0400, Mike Frysinger wrote: > On Tue, Sep 14, 2010 at 01:26, Artem Bityutskiy wrote: > > On Mon, 2010-09-13 at 21:21 -0400, Mike Frysinger wrote: > >> ... policy is for the end user to determine ... this is putting > >> artificial limits for no real reason that i can see. > > > > But the problem is not artificial limits. The problem is that I do not > > think your option is usable at all, because, as I explained, bad > > eraseblock is not necessarily writable, it's contents and the state is > > unpredictable. It may contain unstable bits, for example. You really > > need to erase it before writing. > > it is completely artificial. as you said yourself, it is "not > necessarily writable". that means i should be able to tell the > hardware "do XXX" and let the hardware do it. instead, i'm stuck with > userspace utils that say "no, you cant do that". except the only > thing telling me i cant do that is the userspace utils. as clearly > demonstrated, adding this option lets me do what i want -- write to > pages and change their contents. > > the fact that i might not get the same data back as what i wrote is > completely irrelevant. i can already do this to good pages without > erasing them first. by your logic, nandwrite should also be > artificially aborting with "oh, you need to erase these blocks first". > but it isnt > > the fact that normally you want to skip badblocks is also irrelevant. > that's why it is an option the user specifically needs to enable > themselves. i dont care if the default policy is "dont write to bad > blocks". the default policy has no bearing here. > -mike You are pushing for this quite aggressively, so I guess you really need this :-) And you sound convincing, but give me some time to think about this please. -- Best Regards, Artem Bityutskiy (Артём Битюцкий)