Re: nand oob layout assumptions

[Thomas Gleixner <tglx@linutronix.de>]

On Saturday 27 March 2004 17:18, David Woodhouse wrote:
> On Sat, 2004-03-27 at 10:13 -0600, David Updegraff wrote:
> > In all this discussion, the need for anyone outside the driver to know
> > hardware positions of ECC and badblock markers still elludes me.  Yes,
> > various FS need to scribble oob info of their own in a particular
> > format, and in a way that won't scribble over ecc/badblock, but is there
> > anything more than that?
>
> Nope. The file system just need to be told which are bad blocks, where
> the ECC data are, and which bytes are still available. In fact, it
> possibly doesn't even need to know where the ECC data are in the general
> case.
>
> > So, again, what if the 'oobsize' and 'oob_buf' (or a renamed relative
> > thereof) were interpreted to mean "region available in OOB for misc.
> > file system housekeeping, that will not stomp on private ECC or badblock
> > areas and will not be interpreted by nand driver".  And let the driver
> > put it wherever it wants/needs to in OOB.  Driver gets to ignorant of FS
> > details, FS gets to be ignorant of chip-HW-dependent ECC and badblock
> > layout.
>
> Seems reasonable. We can make it a bitmask of available bytes, perhaps?

I'm tired to repeat myself. 

1. This will break existing code and I'm not willing to do so
We accepted in a long discussion 2 years ago, that we support fs supplied ECC 
layouts. YAFFS relies on this. 

2. Putting stuff into any random place is not a thing I want to have.
Changing one line in the placement code will break all existing fs at once. 
Changing an oob layout in a fs driver just breaks this and solely this 
filesystem. 

It may be better and nicer and more clever to have this independent, but
will you explain the people which are using YAFFS on a SmartMedia Card, that 
they can either freeze the current code or accept that the already existing 
cards are not longer readable ? This is valid for soldered flash too. Update 
of existing hardware to a more recent kernel is then not longer possible 
without loosing data. 

I'm not against an _extended_ API, which provides such things for new 
developments, but I'm cowardly refusing to break compability of existing 
stuff.

Can you please accept the matter of fact that breaking existing 
implementations, which are used on removable medias, is not possible.
Thats like changing the FAT or the ISO driver is not possible even if there 
could be better designs available.

Breaking such things only for the sake of a slightly cleaner interface is the 
playfield of M$ and friends. Linux has a good standing for long term 
stability of interfaces and this is a reason for industrial users to choose 
it. They are tired of changing stuff in short intervals, as the lifecycle of 
such products are higher than the M$ incompabilty rate. And now we want to go 
for the same ?

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