On Mon, 17 Apr 2000, Andrew Brown wrote:

> >To my mind, the interesting thing about the kernel is that it's much like
> >writing for a different system.  You're still writing in C, but what looks
> >like pre-emptive multitasking from above suddenly turns out to be
> >co-operative, and virtual memory turns out to be all too real.  Half your
> >friends from libc (like malloc() and free()) turn out to have different
> >arguments, too.
> 
> and null pointers give you a "different kind" of core dump.  :)

*grin*  Yes, like causing SWI (system call) instructions to enter the page
fault handler.  That was a silly one.

> >As for how to get to know the kernel, try porting it to new hardware.  The
> >past few months has taught me more about how the kernel works than any
> >amount of source browsing could have.  Writing new device drivers for an
> >existing port is a good way to get started, but spares you the really _fun_
> >bits of kernel programming.  Understanding fork() and exit() from the inside
> >is a rather mind-bending experience.
> 
> this is something that i *wish* i had the time and expertise to do.
> oh...and the hardware.  i know there are plenty of platforms left out
> there...i just don't have any of them.  :)

Expertise can be learned.  Hardware is free (if it's old enough).  Time
and documentation are the killers.

> one thing that would be "helpful" in generic porting efforts would be
> a list of the things (functions, macros, defines and constants, etc)
> that the md code actually provides.  is there such a list somewhere?

I found that I could get a pretty comprehensive list by compiling a kernel
for a new architecture and seeing where it fell over.  I agree that some
documentation of that layer is needed, but keeping it up to date is liable
to be painful.

Actually, just a list of what belongs in which header files would be
really useful.

-- 
Ben Harris
Unix Support, University of Cambridge Computing Service.
E-mail: bjh21@cam.ac.uk  Tel: +44 (0)1223 334728  Fax: +44 (0)1223 334679