On 1/19/07, Charles Manning <manningc2@actrix.gen.nz> wrote:
> On Tuesday 16 January 2007 17:42, Aubrey Li wrote:
> > Hi all,
>
> > Has the patch been applied in CVS?
>
> I have just applied a cleaner version of the patch to CVS.
> Instead of more #ifs in the code it only does them in a macro near the
> beginning (and in a ops pointer structure).

Verified. Thanks a lot.

>
> >
> > Another issue is my thoughts about the source code.
> > In my opinion, the current source code is terrible. KERNEL VERSION
> > macros is everywhere. I hate it very much. It caused the code ugly.
> > Since we have the CVS, why not maintain it by cvs tag/branch? for
> > example tag_2-6-18 for kernel(2,6,18), tag_2-6-19 for kernel(2,6,19)?
>
> This is an unfortunate result of kernel changes. Some of them good, some of
> them not so good, combined with the fact that many people find a kernel they
> are comfortable with and settle down.
>
> I don't think that tags in cvs would help because many of the changes are not
> kernel specific. If we add a new feature to yaffs then we'd like it to be
> available to people still using 2.4. How could we do that with tags?
>
> >
> > If we still add kernel version control in the source code, the code
> > will become more and more un-maintainable soon.
>
> The #if code is only in two places: yaffs_fs.c and yportenv.h
>
> I really **hate** seeing #if's inside code (it should preferably only be in
> config stuff, IMHO) which is why all the tracing etc is done with macros
> instead of #ifs.
>
> While I agree it would be neater if we discarded support of historical kernels
> I think that approach is far from useful to the community in general and
> would be completely impractical.
>
> Given the choice between a taste issue and being realistic and supporting
> historical kernels, the taste issue loses.
>
> 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. So

1) KERNEL_VERSION is not needed.
2) new feature is only added to the latest version and future.

So I think it may be reasonable for yaffs. Maintaining all of the
kernel version may be a disaster sooner or later. But yes, that means
the new feature doesn't support for historical kernels. Just my
thoughts, :)

-Aubrey