Large block NANDs - preliminary diff (2)
David Updegraff
dave at cray.com
Fri Mar 26 11:13:48 EST 2004
llandre.
Thanks for your work and patch. I may well be deluded, but aside from
the large-page-inefficiencies vis.a.vis. file system allocations, it
still seems to me we have some OOB troubles with the existing API.
Because oob layout is exported, whereas I think oob layout should be
hidden in the driver.
From what I see, there are three reasons for anyone outside the driver
to know about oob: ecc, badblock and fs-specific data.
For ecc, they only need to set ON or off for the whole chip, for
badblock its a boolean per page or block. And FSDATA is some stuff that
the filesystem wants to scribble on its own, that the driver does not
interpret.
For ecc, there is already an ioctl that can set it generically, if you
ignore the .eccpos bytes. And badblock also has a function pointer in
the driver.
What remains is a way for the filesystem drivers to scribble their own
bytes of data per page or block. IMHO they should be able to do this
independently. Perhaps that the officially PUBLISHED oobsize and
oob_buf stuff currently in place should infact refer to those regions of
the oob that are OUTSIDE of the internal-driver-managed oob regions
dedicated to badblock marking or ecc tracking. The driver always does
its own ecc calculations anyway: why even let anyone else see that area?
But yes; I know; references to the oob stuff is sprinkled everywhere,
and it'll probably be short-term easier to just add another case:
here&there.
-dbu.
More information about the linux-mtd
mailing list