UUCP Port Turnaround (==> Unix Kernel hacks)

[mcvoy at uwvax.UUCP]

In article <13355 at sun.uucp> guy at sun.UUCP (Guy Harris) writes:
In some article somewhere somebody (Some Body) writes:
- >> You should try the kernel hack on a decent system before dismissing it.
- >
- >I guess it's just the Berkeley philosophy to do things in the kernel
- >whenever possible, even when it's not necessary.
- 
- Oh, good grief!
- 
- 2) There are plenty of things in plenty of kernels that don't,
- strictly speaking, *have* to be there.  Why is file name to i-number
- translation in the UNIX kernel?  Why is canonical-mode tty processing
- in the UNIX kernel?  
- 
- 3) Casually claiming that there's some kind of "Berkeley philosophy"
- that "puts things into the kernel whenever possible" may be
- satisfying, but it's not true.  What are these "things" you're
- referring to?

[Try: network code, yellow pages, file servers, page management (yes, I
 meant that), tty drivers (you're right Guy, they shouldn't be there
 unless needed, see version 8), etc.  What's the old kernel up to these
 days, a meg and a half or so?]

My guess, Guy, is that the person in question was referring to the
the _commonly_ held belief that the Berkeley kernel is too large
and seems to be growing without bounds.  I don't think that there is
a "Berkeley philosophy" (or a Sun version either) that says "When in
doubt, throw it in the kernel".  I think that it is much more likely
that the hacker of the moment couldn't see an easier way.

So, rather than blasting this poor soul into Unix exile, why don't we
take a look at why the kernel is so big and what can be done about
(and even, do we want to do anything about it)?

Anyone who uses BSD unix, especially systems programmers, tends to
like it a lot (alright, a blatent overstatement, but some people like it).
The point is that, if you start taking away the functionality of the
current BSD release, people will be unhappy (and rightly so, try doing 
network type code without select someda).  So we don't want that...

Anyone who has to maintain the kernel tends to lose their lunch upon
looking at it for the first time.  Here a hack, there a hack, everywhere a
hack-hack.  My God, that *is* the kitchen sink, isn't it :-?

The problem is that we all like the kernel from the outside, but only
a select masochistic few like it from the inside.  Right?

Well, why don't we take a look at redesigning the kernel?  The goal would be
2 part:

    1) Maintain complete compatibility with the current (or even future)
       BSD release(s).  In other words, it has to work the same as BSD.

    2) Redesign the internal structure to allow easier maintainence and
       flexibility (aka modular design.  Yeah, I hate them software
       engineering words too).  Break it up into the logical parts
       and define some cleaner interfaces.

Sounds good, you say?  Sounds impossible, too?  Sounds possible, but slow?
The last one has it.  This has already been done folks,  the people at
CMU have something called MACH that fulfills both goals.  It's a message
passing kernel based on Accent that is binarily compatible with 4.3BSD on 
Vax, source compatible elsewhere.  It's supposedly well designed,
easy to maintain, and has some new features that make Unix look sick (like
copy-on-write MM, used to get pass-by-value saftey with pass-by-reference
speed, msg based so networking is cake, user loadable drivers, pagers,
etc).  Oh yeah, almost forgot, they have light weight processes to address
the speed issue (all kernel processes are light weight) and they claim
to have performance comparable (in some cases better than) to a BSD
implementation.  Check it out.

So, Guy, the person you blasted was not so far off base, methinks.  You 
don't want me to think that you, of all people, like the fact the kernel
is huge and cumbersome, do you?  Or does playing wizard really mean that
much to you?

Food for thought,

--larry
-- 
Larry McVoy 	        mcvoy at rsch.wisc.edu, 
      		        {seismo, topaz, harvard, ihnp4, etc}!uwvax!mcvoy

"They're coming soon!  Quad-stated guru-gates!"