In article <20000417105653.A12462@noc.untraceable.net> you write:
>>...hacking on the kernel is really not that different from hacking on
>>userland.  The major differences can be summed up as "no safety net":
>>if you slip up you can take down the whole system instead of just the
>>userland process in question.  But since you'd presumably be doing it
>>on a crash-&-burn machine anyway....
>
>i always like it when people say this.  :)
>
>yeah...hacking on the kernel is (a) just like userland, (b) but
>larger, and (c) with no safety net, but it's also really different.
>
>it's wildly different.  there are things that go on in the kernel that
>are wildly different from anything that goes on anywhere else in the
>system: vm management, networking, file system layout strategy and
>allocation, auto-configuration...things i don't yet understand at all.
>not that i know how to write a compiler either, but...

Those are just because the kernel does a different job to most userland
programs.  If you looked at the insides of a serious database, you'd
probably find they did the same kinds of thing.

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.

One odd discovery I made recently is that writing networking code for the
Mac OS is very similar to writing Unix device drivers.

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.

-- 
Ben Harris