All of lore.kernel.org
 help / color / mirror / Atom feed
From: Artem Bityutskiy <dedekind1@gmail.com>
To: Mike Frysinger <vapier@gentoo.org>
Cc: linux-mtd@lists.infradead.org
Subject: Re: [PATCH] nandwrite: add --nobad to write bad blocks
Date: Wed, 22 Sep 2010 10:12:50 +0300	[thread overview]
Message-ID: <1285139570.7512.137.camel@localhost> (raw)
In-Reply-To: <AANLkTin+2ocUT_NMToGHoAhX5=Trn2CdLFmiMBmvSVuC@mail.gmail.com>

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 (Артём Битюцкий)

  reply	other threads:[~2010-09-22  7:14 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-09-12  3:51 [PATCH] nandwrite: add --nobad to write bad blocks Mike Frysinger
2010-09-12 16:27 ` Artem Bityutskiy
2010-09-12 19:05   ` Mike Frysinger
2010-09-13  6:23     ` Artem Bityutskiy
2010-09-14  1:21       ` Mike Frysinger
2010-09-14  5:26         ` Artem Bityutskiy
2010-09-22  4:23           ` Mike Frysinger
2010-09-22  7:12             ` Artem Bityutskiy [this message]
2010-09-22  7:34               ` Mike Frysinger
2010-09-29  3:35                 ` Iwo Mergler
2010-09-29  6:56                   ` Jon Povey
2010-09-29 13:25                     ` Mike Frysinger
2010-09-29 23:44                     ` Iwo Mergler
2010-09-30  3:23                       ` Jon Povey
2010-09-29 12:59                   ` Artem Bityutskiy
2010-09-29 13:28                     ` Mike Frysinger
2010-09-30  3:51                       ` Jon Povey
2010-09-23  1:48             ` Jon Povey
2010-09-23 10:38 ` Artem Bityutskiy
2010-09-23 20:04   ` [PATCH v2] " Mike Frysinger
2010-09-24  8:50     ` Artem Bityutskiy
2010-09-24 12:33       ` Mike Frysinger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1285139570.7512.137.camel@localhost \
    --to=dedekind1@gmail.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=vapier@gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.