Vitaly,
On Sat, 2006-02-18 at 19:31 +0300, Vitaly Wool wrote:
> Hi folks,
Can you please stop top posting ?
> just two small notes from my side.
> First, FWIW, YAFFS2 never writes OOB w/o data and that looks more proper
> than JFFS2 style which means cleanmarkers for an empty page.
> YAFFS2 just needs means to be agnostic about how OOB bytes are placed
> within a page.
I'm not too happy about this JFFS2 oddity and I would remove it better
today than tomorrow.
The agnostic thing is fine, but it still is not solving the fundamental
flaw of oob usage at all. The only guarantee of NAND is that you can
store data size, but the size of the "free" bytes in OOB (due to ECC,
bad block markers ...) is non constant and depends on hardware design,
chip types ... So any self restriction of a filesystem, block emulation
layer or whatever user of NAND flash to a small number of bytes it wants
to put into OOB can not cover _all_ possible constellations.
The kernel can only provide generic solutions and it makes absolutely no
sense to rely on nifty tricks which require code bloat and can not cover
every corner case.
> Next, I took a look at rtc_from4.c and I'm not sure how to follow this
> method if the NAND controller just doesn't have means to give the
> caclulated ECC back to user. Thomas, could you please elaborate on that?
-ENOPARSE. What does the NAND controller do with the calculated ECC, if
it has no way to let the user read the ECC ?
You mean those controllers which insert the ECC automatically at some
point into the data stream ? A great example why OOB usage is not a good
idea at all. These controllers guarantee data size and nothing else. I
have one on my desk which does not let you use OOB, because it does all
the magic itself.
tglx
(text/plain)