nand oob layout assumptions

[Thomas Gleixner]

On Sunday 28 March 2004 09:34, Charles Manning wrote:
> > But the fs must be aware of the bad block marker position in the OOB
> > area, as it can not use this byte for storing fs dependend data. The OOB
> > usage is given by the fs layer.
>
> No. Part of the deal is that the OOB area should not be shown in "raw" form
> to the fs. There should be no l physical placement knowledge in the fs,
> only abstract.
>
> This should be shown to the fs as:
>   __u8 spare[8];
>   ECCResult (OK, fixed, failed)
>   BlockOK (OK, bad)

OK, I already have agreed, that we can use such an abstract form for new 
developments, but we _MUST_ maintain compability for the existing 
implementatitons. I like abstract models very much, but I will always keep in 
view what consequences we will have, if we change things.

That's all I'm insisting on.

YAFFS1 uses a different ECC placement than JFFS2. 
If we change this in general now, we will either break YAFFS or JFFS2 or even 
both. 

This prevents users to upgrade their kernels. They will have format 
incompabilities so they loose data on upgrading or loose the interoperability 
of systems. Will you tell your customer to either upgrade 1000 already sold 
devices or stick with the current code or accepting that interoperability is 
not given ? That's not what Open Source Software stands for.

I do not have any objections against an API extension, but breaking things I'm 
_NEVER_ going to accept.

-- 
Thomas
________________________________________________________________________
linutronix - competence in embedded & realtime linux
http://www.linutronix.de
mail: tglx at linutronix.de