Subject: Re: organization within the MIPS tree...
To: Garrett D'Amore <firstname.lastname@example.org>
From: Simon Burge <email@example.com>
Date: 03/05/2006 09:43:07
"Garrett D'Amore" wrote:
> I've noticed that we have tended to put processor specific headers in
> something like:
> this makes it awkward to either deploy headers to the field (not sure
> why we'd want to do that), and also to use them. you have to have
> #includes like this:
> #include <mips/alchemy/include/xxx.h>
> I've noticed that powerpc does it cleaner. They create subdirectories
> underneath powerpc/include, so you can have something like this:
> #include <powerpc/ibm4xx/xxx.h>
> I think that is a lot cleaner. (Losing the redundant "include" bit.)
> And they can then deploy certain headers that may be useful outside the
> Any reason we don't do this for MIPS? Would anyone object too
> strenuously if I changed alchemy to do this? It would be nice to
> convert them all... and I'm willing, but I can't do more than verify
> that the kernels still build, as I don't have e.g. a sibyte class machine.
For PowerPC, the ibm4xx and oea subdirectories contain pmap/MMU type
info because there is two wildly different pmaps on this architecture.
There are also a handful of device type files in there too, but only
because the directory already exists. These pmapish files need to be
installed in userland, so that's why they're in arch/powerpc/include.
In MIPS land, there's only a single pmap even though the r3k and r4k
MMUs are a bit different - these differences are mostly contained to
mips1_pte.h and mips3_pte.h in arch/mips/include.
For the alchemy and sbmips, there's no files in their "private" include
directories that need to be installed in userland so I think it's
cleaner to leave them self-contained.
Simon Burge <firstname.lastname@example.org>
NetBSD Support and Service: http://www.wasabisystems.com/