What SHOULD go in the kernel

[John Chambers]

In article <47040 at bbn.COM>, news at bbn.COM (News system owner ID) writes:
> jwr at ektools.UUCP (Jim Reid) writes:
> < Is there a rule of thumb of what should and should not be put in the
> < kernel?  To be more specific, is it better to make a device driver 
> < 'lean-and-mean' or sophisticated, so that the user interface (the read(),
> < write(), ioctl()) is simpler?
> 
> As little as possible?. (both a statement and a question)
> 
> First off, kernels are generally harder to debug than user programs,
> so the less stuff you add there the better off you will be.  Also,
> most kernels won't do VM on themselves (for several _good_ reasons
> :-) ), so any extra code you put in the kernel will be sitting there
> taking up space even if you don't need it right now.

[This is too good to pass up. ;-]  I'd like to observe that, though
this may be correct from a software-engineering point of view, it is
incorrect from a career-interest point of view.  I've made the mistake
of minimizing the kernel work on quite a few projects.  Now when I go
to interviews, it is clear what the result is.  Such design isn't ever
taken as evidence of practicality, good engineering practice, or any such
thing.  It is merely evidence that I am a Unix kernel lightweight.  At
a time when Unix-kernel/device-driver experts are getting roughly 50%
more bucks than those who work at the "application" level, it is clear
what a fool I've been.

Lately, I've been following people's advice here, and writing programs
that grovel around in a filesystem's raw device.  This could turn out 
to be a bad idea.  Once again, I've done it outside the kernel.  But
I have an excuse:  This is an object-only system.  If I had the source,
you bet I'd do it in the kernel (especially since in this case, it'd 
be easier).

> Personally, I'd go for lean and mean just 'cause.  Very seldom is fat
> and featureful better than lean and mean, especially in a kernel.
> Compare, for instance, v9 and SunOS 4.  (yes, it _is_ an often
> repeated cheap shot at Sun, but it's also _true_.)

In particular, there's a good demand for people with significant Sun
internals experience.  It can be hard to get this experience, due to
the shortage of source code at most Sun customer sites.  If you have
it available, the sensible advice is "Go for it."  If you have doubts
about whether it's for the best of your current employees, you might
try asking them whether they'd pay more for a Sun internals expert than
for a Sun applications programmer.  Then go with their answer.  

> 	-- Paul Placeway <PPlaceway at bbn.com>
> 	   Am I a wizard?  Are you qualified to judge?  Does it really
> 	   matter in the end?  "What I am is what I am, are you what
> 	   you are or what?" -- E.B.

In the current economy, much judging is done by those unqualified to
judge.  That's why there's so much dependence on credentials.  It's
hard to see how it could be any other way in a field with such rapid
technology change.

In response to the expected flames, I'll just pre-ask a pertinent
question:  If you want a job done right, shouldn't you be rewarding
those who do it right, rather than those that do it the hard way?

(I might also observe that Mach may bad news for kernel experts; it
seems they've moved a lot of stuff out of the kernel.... ;-)

-- 
#echo 'Opinions Copyright 1989 by John Chambers; for licensing information contact:'
echo '	John Chambers <{adelie,ima,mit-eddie}!minya!{jc,root}> (617/484-6393)'
echo ''
saying