On Thursday 07 July 2005 07:00, 
yaffs-request@stoneboat.aleph1.co.uk wrote:
> I know this will make you cringe, but just so you know....
> I have taking 2.6 mtd and yaffs2 code and back ported them to
> the 2.4 kernel.
> I know someone will suggest that I switch to 2.6, but that is
> not an option for me.

I am having to do something similar.  We have been using YAFFS1 
on a 2.4.24 base with MTD from November 2004. Now we need large 
block support (YAFFS2).  I took the last version of MTD that was 
said to run with 2.4 (cvs update -dP -D 2005-03-04) and I fixed 
it up to run with YAFFS2. I suspect that the MTD user base is 
primarily 2.4 based embedded systems and support for 2.4 will be 
needed for a long time yet.

There seem to be a number of issues with the interface between 
the filesystem (YAFFS) and MTD (2005-03-04). The most 
significant is with MTD's mtd->read_oob function, i.e. 
nand_read_oob(). JAFFS2 needs 'autoplacement' functionality on 
this function (used during initial scan to examine tags), but 
MTD uses it internally (bad block scan etc.) and that requires 
read_oob to provide raw oob/spare data. I hacked nand_read_oob() 
to do autoplacement when called by yaffs (using a null retlen 
ptr as a hack to signal need for autoplacement).

There are a number of other areas where the API between the 
filesystem (yaffs) and MTD are broken. I know there is a lot of 
focus on developing JFFS3, but I think MTD itself should be 
fully revised. Linux MTD has evolved and lessons have been 
learned -- memory technology devices are evolving. MTD needs 
re-layering with cleaner abstractions between the layers. If 
this were done, it would be easy to support MTD on different 
major revisions of Linux, and it may port easily to other 
platforms (as yaffs does).

-imcd