Re: Large block NANDs - preliminary diff (2)

[David Updegraff <dave@cray.com>]

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.