[nycbug-talk] kernels

[Roland C. Dowdeswell]

On 1086290822 seconds since the Beginning of the UNIX epoch
Pete Wright wrote:
>

>yea this is crazy.  this bantering doesn't even relate to the 
>article/thread either :(  i was hoping people would more interested in 
>the micro v. monolithic kernel issues, esp. seeing that apple has 
>adopted MACH.  sigh.

Well, the thread pointed to wasn't talking about micro vs. monolithic
kernels, it was just talking about LKMs which are substantially
less interesting.

It did have an assertion that I think is rather suspect, in that
it claimed that a fully LKMed system would outperform a non-LKMed
implementation.  This, I think is a false statement.  Using LKMs
you can save memory, but it does not speed up execution at all.
In fact, it slows execution down.  It is done simply for convenience
(some definition thereof, sure.)

E.g. by not using LKMs, one can have #ifdef's in multiple places in
the code that all depend on a single feature being active.  As in,
if I do not want a packet filter in my kernel, then I do not define

options PFIL_HOOKS

and the if statement that checks to see if there are any registered
packet filters that need to be called is elided from the resulting
kernel.  This sort of thing makes execution faster.  It's a cheap
form of global optimisation.  If we had C compilers that performed
reasonable global optimisation then LKMs would be a bit more of a
penalty (but I do not think that we do.)

[of course that last bit doesn't apply to OpenBSD because although
 they offer the functionality I outlined they do not `support' it.
 NetBSD does support kernels with modified config files.]

--
    Roland Dowdeswell                      http://www.Imrryr.ORG/~elric/