On Tuesday 16 August 2005 03:09, Ian McDonnell wrote:
> On Sunday 14 August 2005 15:35, Charles Manning wrote:
> > Right now there is a major code clean up etc underway. This
> > should be completed in the next few days.
> >
> > At present there is a small issue with the mtd interface and
> > the way it handles read_oob (it does this raw instead of doing
> > AUTOPLACE). When the new AUTOPLACE mechanism is in place, then
> > YAFFS will use that mechanism in preference to yaffs_Spare.
> > This should make things a lot cleaner.
> >
> > This is high priority on the YAFFS side and (hopefully) on the
> > mtd side. I expect this issue to be resolved before the end
> > of this month. In the mean time, you'll just need to hack
> > either YAFFS or the mtd to get what you need.
>
> Does anyone hold out hope that the changes required to fixup
> MTD would ever make into a version that's usable with a 2.4
> kernel? See
> http://www.linux-mtd.infradead.org/source.html#kernelversions
>
> If necessary, and I'm sure it will be, can we put together an
> MTD patch that will fix this 'small issue'. The MTD hack I
> sent to this list illustrated the problem, but it does not
> provide a general solution.
The world would be a very boring place if we all agreed on everything. The 2.4
support issue is one on which I happen to disagree with the mtd folks.
I understand the point of view that keeping 2.4 support increases testing and
compatability, but I don't think it is realistic to force folk over to using
2.6 in near mocking tones. We don't always have an opportunity to turn over
the page and shift our software.
From a YAFFS perspective, the current clean-up effort has been done with a 2.6
focus, with no intention of breaking any 2.4 stuff.
The NAND portion of mtd required by YAFFS is very simple - far less than is
provided by mtd - and there are two ways I think this can be achieved:
1) Some sort of patch set against an older mtd.
2) A stripped down NAND driver that uses very little mtd code (except for the
registration etc services). I have heard of a few instances of people doing
this to get improved performance.
BTW: I'm not knocking Thomas' efforts here. It is inevitable that a code body
like nand_base.c that tries to cater for all types of nand and all usages
will not be the optimum solution for any any one set of hardware + file
system. Generic code costs.
-- Charles
(text/plain)