All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
To: David Woodhouse <dwmw2@infradead.org>
Cc: Richard Genoud <richard.genoud@gmail.com>,
	zhouguangming@innofidei.com,
	Hans Zhang <zhanghonghui@innofidei.com>,
	linux-mtd <linux-mtd@lists.infradead.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] Make the mtdblock read/write skip the bad nand sector
Date: Mon, 25 Nov 2013 09:30:13 -0300	[thread overview]
Message-ID: <20131125123012.GE2408@localhost> (raw)
In-Reply-To: <1385381770.24518.18.camel@shinybook.infradead.org>

David,

On Mon, Nov 25, 2013 at 12:16:10PM +0000, David Woodhouse wrote:
> On Mon, 2013-11-25 at 08:52 -0300, Ezequiel Garcia wrote:
> > 
> > Your understanding is correct: NAND *must* be erased explictly in
> > userspace
> > before writing. However, keep in mind the following additional
> > constraints:
> > 
> > * Writing should be always performed using 'nandwrite',
> >   not tools such as 'cat' or 'dd'.
> > 
> > * An mtdblock shouldn't be used to access directly the NAND from
> >   userspace. AFAICS, the primarily usage of mtdblock is to be able to
> >   mount JFFS2.
> 
> No. You don't need mtdblock to mount JFFS2 at all.
> 
> The mtdblock driver was used in the *very* early days of the MTD system,
> on NOR flash with a "traditional" file system. Either in read-only mode
> for something like cramfs, or in a very unsafe writeable mode. We
> actually put ext2 on it for the Compaq iPaq for a while, before we had
> JFFS.
> 
> It was used as a shortcut for mounting JFFS2, and still is by a lot of
> people, but it's certainly not necessary. You can turn off CONFIG_BLOCK
> entirely and still use JFFS2.
> 
> You should consider mtdblock to be the most basic, primitive, "flash
> translation layer" that can possibly exist. And thus, should basically
> never use it. I certainly don't approve of trying to extend it.
> 

Thanks a lot for the insight. After reading this, I'm wondering what's
preventing us from killing MTD block support altogether. Artem, already
suggested it a while back...
-- 
Ezequiel García, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com

WARNING: multiple messages have this Message-ID (diff)
From: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
To: David Woodhouse <dwmw2@infradead.org>
Cc: Hans Zhang <zhanghonghui@innofidei.com>,
	Richard Genoud <richard.genoud@gmail.com>,
	linux-mtd <linux-mtd@lists.infradead.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	zhouguangming@innofidei.com
Subject: Re: [PATCH] Make the mtdblock read/write skip the bad nand sector
Date: Mon, 25 Nov 2013 09:30:13 -0300	[thread overview]
Message-ID: <20131125123012.GE2408@localhost> (raw)
In-Reply-To: <1385381770.24518.18.camel@shinybook.infradead.org>

David,

On Mon, Nov 25, 2013 at 12:16:10PM +0000, David Woodhouse wrote:
> On Mon, 2013-11-25 at 08:52 -0300, Ezequiel Garcia wrote:
> > 
> > Your understanding is correct: NAND *must* be erased explictly in
> > userspace
> > before writing. However, keep in mind the following additional
> > constraints:
> > 
> > * Writing should be always performed using 'nandwrite',
> >   not tools such as 'cat' or 'dd'.
> > 
> > * An mtdblock shouldn't be used to access directly the NAND from
> >   userspace. AFAICS, the primarily usage of mtdblock is to be able to
> >   mount JFFS2.
> 
> No. You don't need mtdblock to mount JFFS2 at all.
> 
> The mtdblock driver was used in the *very* early days of the MTD system,
> on NOR flash with a "traditional" file system. Either in read-only mode
> for something like cramfs, or in a very unsafe writeable mode. We
> actually put ext2 on it for the Compaq iPaq for a while, before we had
> JFFS.
> 
> It was used as a shortcut for mounting JFFS2, and still is by a lot of
> people, but it's certainly not necessary. You can turn off CONFIG_BLOCK
> entirely and still use JFFS2.
> 
> You should consider mtdblock to be the most basic, primitive, "flash
> translation layer" that can possibly exist. And thus, should basically
> never use it. I certainly don't approve of trying to extend it.
> 

Thanks a lot for the insight. After reading this, I'm wondering what's
preventing us from killing MTD block support altogether. Artem, already
suggested it a while back...
-- 
Ezequiel García, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com

  reply	other threads:[~2013-11-25 12:30 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-21  8:54 [PATCH] Make the mtdblock read/write skip the bad nand sector Hans Zhang
2013-11-21  8:54 ` Hans Zhang
2013-11-21 10:59 ` Richard Genoud
2013-11-21 10:59   ` Richard Genoud
2013-11-22  1:22   ` Hans Zhang
2013-11-22  1:52     ` Ezequiel Garcia
2013-11-22  1:52       ` Ezequiel Garcia
2013-11-22  2:10       ` Hans Zhang
2013-11-22  8:14         ` Richard Weinberger
2013-11-22  8:14           ` Richard Weinberger
2013-11-22 11:45         ` Ezequiel Garcia
2013-11-22 11:45           ` Ezequiel Garcia
2013-11-25  1:29           ` Hans Zhang
2013-11-25 10:11             ` Ezequiel Garcia
2013-11-25 10:11               ` Ezequiel Garcia
2013-11-25 10:23               ` Richard Genoud
2013-11-25 10:23                 ` Richard Genoud
2013-11-25 11:30                 ` Hans Zhang
2013-11-25 11:52                   ` Ezequiel Garcia
2013-11-25 11:52                     ` Ezequiel Garcia
2013-11-25 12:16                     ` David Woodhouse
2013-11-25 12:16                       ` David Woodhouse
2013-11-25 12:30                       ` Ezequiel Garcia [this message]
2013-11-25 12:30                         ` Ezequiel Garcia
2013-11-25 15:12                         ` Peter Korsgaard
2013-11-25 15:12                           ` Peter Korsgaard
2013-11-25 15:46                           ` David Woodhouse
2013-11-25 15:46                             ` David Woodhouse
2013-11-29 13:26                             ` Pavel Machek
2013-11-29 13:26                               ` Pavel Machek
2013-12-10  7:43                               ` Brian Norris
2013-12-10  7:43                                 ` Brian Norris
  -- strict thread matches above, loose matches on Subject: below --
2013-11-21  8:39 Hans Zhang
2013-11-21  8:39 ` Hans Zhang

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=20131125123012.GE2408@localhost \
    --to=ezequiel.garcia@free-electrons.com \
    --cc=dwmw2@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=richard.genoud@gmail.com \
    --cc=zhanghonghui@innofidei.com \
    --cc=zhouguangming@innofidei.com \
    /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.