"Garrett D'Amore" wrote:

> I've noticed that we have tended to put processor specific headers in
> something like:
> 
> src/sys/arch/mips/alchemy/include/xxx.h
> 
> 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
> kernel.
> 
> 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.
--
Simon Burge                            <simonb@wasabisystems.com>
NetBSD Support and Service:         http://www.wasabisystems.com/