On Thursday 01 November 2007 17:18, you wrote:
> > On Tuesday 30 October 2007 17:01, Martin Fouts wrote:
> > > All of the changes made *should* be cosmetic on a yaffs
> > > Linux or yaffs
> > > direct port, but I don't have either to test against.
> >
> > Unfortunately not, there are a whole bunch of problems with
> > missing types for the list macros. I tried something quick
> > to fix it and it didn't work. I'll tidy up the whole
> > yportenv.h vs. devextras.h thing for the linux builds and
> > see how that sits, then lets make a new patch for your
> > changes.
>
> Sorry about that.  This weekend I'll set up something to allow
> me to test that my patches at least apply correctly and
> compile on a Linux kernel before I send them along.

If you have the urge to clean-up the includes/defines etc.
go ahead.  I was thinking of something like:

1) definitions/macros etc. that are always needed go
   in a main header file -- these have to be OS neutral.

2) a choice of definition/macros for host X, host Y,
   host Z, etc., each in a separate header file.

3) some makefile config options/defines (eg. YAFFS_NETBSD,
   YAFFS_LINUX, YAFFS_DIRECT) that determine:
	a) which OS header (X.h, Y.h, Z.h) to include
	b) which source files are built

4) perhaps separate Makefile.{X,Y,Z} for each OS variant
   written in a form that is natural for the OS in question.
   This should include the mechanism used to configure Yaffs.
   [in-tree and out-of-tree linux builds would be separate
   makefiles, this covers the in-tree case where Yaffs
   config becomes part of kernel config].

Although I never used Yaffs or MTD on Linux-x86, I have 
accidentally built it for x86 just fine.  So you should
be able to do the same -- I was using Fedora Core 5 at the
time, but that shouldn't matter so long as the linux MTD
headers are available.

-imcd