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
(text/plain)