On Tuesday 23 January 2007 03:59, ian@brightstareng.com wrote:
> On Sunday 21 January 2007 23:16, Aubrey Li wrote:
> > > So long as the kernel folk don't speed up on the number of
> > > arbitrary changes they make, we should not experience too
> > > much further problems. Right now we support all flavours
> > > from 2.4.something to current with only a few (44 by my
> > > count)  KERNEL_VERSION #ifs in yaffs_fs.c. I really don't
> > > think we're anywhere near crumbling point yet.
> >
> > Well, it's really a big headache. Obviously kernel folk will
> > change the framework/API etc constantly. I'm thinking of if
> > yaffs is accepted into kernel, it will be released in
> > different version.
>
> Perhaps some additional levels of abstraction or simple
> factoring out of some code segments in functional areas
> that have too many ifdefs will help manage the situation.
> Is it amazing how portable and change-resilient code can be
> once the right pattern and abstraction is reached.
>
> Unfortunately I don't have time to work in this myself at
> the moment.  But please don't give up with the 2.4 interface --
> there are surely many more 2.4-based products out there that
> need to be supported at this time, than 2.6.

That is indeed the crux of the matter. I know of no embedded folk who are 
switching to new kernels as they are released. Many people are still using 
2.4, or an early 2.6 and will continue to do so.

yaffs_fs.c is approx 2000 lines and has approx 40 kernel version #ifs. That is 
messy, but not extremely so. To my mind a bit of messiness is worth the 
benefit of supporting all.

I don't think we're getting anywhere near a crumbling point. Adding the 2.6.19 
changes was very simple and surgical and only involved a few lines. And using 
wrapper macros, as Ian suggests, and as I did in the 2.6.19 support, reduces 
the clutter considerably.

Some refactoring (particularly arountd the mtd set-up) would clean things up. 
If someone is motivated to do so, that is great.

-- Charles