From: Thomas Gleixner <tglx@linutronix.de>
To: manningc2@actrix.gen.nz, David Woodhouse <dwmw2@infradead.org>,
David Updegraff <dave@cray.com>
Cc: linux-mtd@lists.infradead.org
Subject: Re: nand oob layout assumptions
Date: Sun, 28 Mar 2004 09:05:51 +0100 [thread overview]
Message-ID: <200403281005.51480.tglx@linutronix.de> (raw)
In-Reply-To: <20040328075658.221981764D@desire.actrix.co.nz>
On Sunday 28 March 2004 10:06, Charles Manning wrote:
> I agree with the idea of abstacting this as much as possible. Where the EEC
> is stores (if indeed it even is stored in OOB) should not be the FS's
> concern and should not be known to the FS. The FS should just be told that
> the ECC passed, failed or fixed a single bit error.
No problem with that
> Unless we go for one abstract interface it will [continue to] be hell to
> support more than one FS (it is already a /dev/ass/pain to try get YAFFS
> and JFFS2 going on one machine due to different OOB layouts). The [already
> bad] situation will only get worse when trying to deal with all the fun
> that the newer NAND devices bring us.
He ? I'm running YAFFS and JFFS2 since a long time on the same device and it
works without any PITA.
I just want to bring back into memories, that we had a long discussion about
an abstract interface 2 years ago. There was no way to find a common solution
as nobody was willing to break either JFFS2 or YAFFS1 or both.
Again. I agree with the idea of an abstract interface as long as we keep the
current stuff running.
> No bitmask. That just passes mucky knowledge through the interface.
>
> Rather:
> * Have the mtd tell the FS the number of unused bytes in the OOB.
> * Pass a byte array through the interface and the mtd packs/unpacks this
> around the ECC, bad block markers and other stuff.
No objections.
--
Thomas
________________________________________________________________________
linutronix - competence in embedded & realtime linux
http://www.linutronix.de
mail: tglx@linutronix.de
next prev parent reply other threads:[~2004-03-28 8:09 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-03-25 18:44 nand oob layout assumptions David Updegraff
2004-03-25 19:58 ` Thomas Gleixner
2004-03-27 7:40 ` Charles Manning
2004-03-27 8:07 ` Thomas Gleixner
2004-03-27 10:24 ` David Woodhouse
2004-03-27 11:10 ` Thomas Gleixner
2004-03-27 11:25 ` David Woodhouse
2004-03-27 14:15 ` Thomas Gleixner
2004-03-27 16:13 ` David Updegraff
2004-03-27 16:18 ` David Woodhouse
2004-03-27 17:40 ` Thomas Gleixner
2004-03-28 8:06 ` Charles Manning
2004-03-28 8:05 ` Thomas Gleixner [this message]
2004-03-28 7:34 ` Charles Manning
2004-03-28 7:51 ` Thomas Gleixner
2004-03-28 8:19 ` Charles Manning
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=200403281005.51480.tglx@linutronix.de \
--to=tglx@linutronix.de \
--cc=dave@cray.com \
--cc=dwmw2@infradead.org \
--cc=linux-mtd@lists.infradead.org \
--cc=manningc2@actrix.gen.nz \
/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.