UUCP Port Turnaround (==> Unix Kernel hacks)

[mwm at eris.UUCP]

In article <3233 at rsch.WISC.EDU> mcvoy at rsch.WISC.EDU (Lawrence W. McVoy) writes:
>In article <13355 at sun.uucp> guy at sun.UUCP (Guy Harris) writes:
>In some article somewhere somebody (Some Body) writes:
>- >I guess it's just the Berkeley philosophy to do things in the kernel
>- >whenever possible, even when it's not necessary.
>-
>- 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?]

Berkeley hasn't put yellow pages & file servers in the kernel; those
are from Sun. The tty driver was inherited from v7; I don't know
anybody who doesn't think it needs a rewrite. That leaves networking
and page management, which people tend to put into the kernel for
efficiency reasons.

>My guess, Guy, is that the person in question was referring to the
>the _commonly_ held belief that the Berkeley kernel is too large

Possible. But that belief is also common around Berkeley. The question
is how to cleanly get from where we are to where we want to be.

>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 :-?

Anyone who ever grows past the stage of being able to look at kernel
code without wanting to loose their lunch needs help. Fortunately,
there's usually a sink handy :-). 

>[Talk about redesigning the kernel.]
>The last one has it.  This has already been done folks,  the people at
>CMU have something called MACH that fulfills both goals.

Yeah, and the MACH kernel is the second-largest kernel I've ever run.
The largest is ultrix-2, with NFS, SVID compatable up to and including
shared memory, support the an entire new bus structure, and a second
processor.

Also, last time I looked (about 6 months ago), a lot of the neat
features in MACH weren't. Lightweight processes, user-mode file
servers, user-mode 4.3 emulation, etc. Large parts of the kernel were
also 4.3, not MACH. Changing these things could make the kernel
smaller; they could also make it slower.

Of course, the parts that were MACH were readable.  MACH is worth
watching; as it might turn out to be the classic "smaller & faster &
more functional than the original" type clone. But I'd expect "bigger
& slower and more functional," which means I'm not interested (BSD is
big & slow & functional enough as it is).

	<mike


But I'll survive, no you won't catch me,		Mike Meyer
I'll resist the urge that is tempting me,		ucbvax!mwm
I'll avert my eyes, keep you off my knee,		mwm at berkeley.edu
But it feels so good when you talk to me.		mwm at ucbjade.BITNET