One thing that bugs me: there is not a clean line in the kernel
code between code that is arch specific and arch independent.
My humble belief is that any code relies on a arch specific
feature, it should be in the respective 'arch' directory, and not
thrown in with everything else.
A clean division also makes it easier for the kernel code
to be split by arch and 'core' kernel code. This is _NOT_ my
objective though (it is a reasonable one though IMHO).
My objective is simply better organization, which results
in less clutter, and makes the code easier to maintain and
expand.
Things like PCI drivers should be arch independent, as there
are at least 3 arch's using PCI. This code can be considered
'core' kernel code (generic). Any PCI code that is not arch
specific (calls to a PCI BIOS?) should be in an arch specific
area if possible, or #ifdef'ed (for small amounts of code only!).
Examples of dependent code:
- there isn't an 'arch' directory for arch specific headers.
'asm' is currently being used for this, but its naming
implies assembly-only stuff. Perhaps it should be renamed,
or a new 'linux/include/arch' symbolic directory link added.
- each driver subdirectory is chock full of drivers, some of
which are _VERY_ platform specific (and some which are not).
This suggest to me there needs to be a link to an arch specific
directory of drivers in each one of these subdirectories.
- there is some arch specific code in parts of the kernel
outside of the 'arch' directory. Example: linux/kernel/dma.c
(NOTE! I've aready nuked this one, and combined it into
an arch independent file (and API) 'hwres.c' in my PnP patch.
There are likely other such files about though.)
- There isn't a standard type for addressing. Some code uses
'unsigned', some code uses 'unsigned long'. Both of these
may be incorrect too since sizeof( void * ) may be different
than the size of either of these. This an arch specific
thing that we shouldn't have to worry about (most of the time),
and hence a generic address type (addr_t?) is needed.
- A lot of code still treats virtual and physical spaces as equal.
- There is a lot of very loosely typed code. Much of this
is because of C itself, but that doesn't mean you can always
get away with certain things on a different arch. Just because
C promotes laziness, doesn't mean you have to or should be lazy!
You can't rely on the compiler to issue you a warning either!
I think we should keep in mind the future, and be hopeful that
someday there will be 'Linux Everywhere' (resulting in a big
'arch' directory and generally a lot more code than today).
Personally, I'd like to see '*nix Inside" stickers on stuff
like VCRs someday :-) (With cable modems comming, this may soon
not be as ludicrous as it first sounds).
The thought of 'Windows Inside' anywhere in a nuclear power plant
(except maybe the candy vending machine) gives me shivers.
-- Andrew E. Mileski mailto:aem@ott.hookup.net http://www.redhat.com/~aem/ Linux Plug-and-Play Project http://www.redhat.com/pnp/Red Hat Software sponsors these pages - I have no other affilitation with Red Hat Software, and I have never used any of their products.