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