Josh Boyer wrote:
> But Charles also wants clean interfaces. I agree that clean
> interfaces are definitely a good thing, but trying to come up with a
> clean interface for OOB access that won't get bastardized seems to be
> unattainable.
But this does not mean that we should remove OOB support. Again, the
right (IMO, of couse) way is to make several levels of generalization.
Just off the top of my head:
1. MTD level: a generic flash model with nothion of eraseblock, a
mimimal I/O unit, read and write operations, nothing else. This level is
for properly designed software.
2. NAND flash level: here you have OOB access. Work in terms of NAND
pages, etc. Here YAFFS could be happy.
3. We could also have a DataFlash layer, where DataFlash guys could make
use of their blocks and sectores, use features note visible from the
topmost generic MTD layer.
> I think at some time in the not so distant future this whole
> conversation will become a moot point. SLC NAND quality seems to be
> degradding as the die sizes go down, and MLC NAND is already of a
> degraded quality comparitively. Better ECC algorithms will be needed
> to provide the reliability that people want and I can see that
> consuming all of the available OOB area anyway.
Still, the argument with CF cards makes me believe that vendors will
provide some space for user data in OOB. Why can't they enlarge OOB size?
--
Best Regards,
Artem B. Bityutskiy,
St.-Petersburg, Russia.
(text/plain)