Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!mit-eddie!husc6!seismo!mimsy!chris
From: chris@mimsy.UUCP
Newsgroups: comp.sources.wanted,comp.unix.wizards,comp.unix.questions
Subject: Re: UUCP Port Turnaround (==> Unix Kernel hacks)
Message-ID: <5463@mimsy.UUCP>
Date: Mon, 16-Feb-87 23:40:55 EST
Article-I.D.: mimsy.5463
Posted: Mon Feb 16 23:40:55 1987
Date-Received: Wed, 18-Feb-87 20:20:55 EST
References: <171@ndmath.UUCP> <4090@nsc.nsc.com> <166@piaget.UUCP> <3233@rsch.WISC.EDU>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 49
Xref: utgpu comp.sources.wanted:559 comp.unix.wizards:1016 comp.unix.questions:1083

In article <3233@rsch.WISC.EDU> mcvoy@rsch.WISC.EDU (Lawrence W. McVoy) writes:
>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.

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

(I think we do, but just what must still be classified `experimental'.)

>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.

To quote from /sys/sys/ufs_xxx.c:

	/*
	 * Oh, how backwards compatibility is ugly!!!
	 */

As for myself, I am not sure compatibility is worth the ugliness.

>     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.  ... 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.

Mach is still `under development'; it remains to be seen whether
all this will really fly.  And if you thought 4.3BSD was big. . . .

To be fair, while the Mach kernel is about twice the size of the
4.3 kernel, it does have full 4.1BSD compatibility, and 4.2
compatibility, and . . . well, you probably get the idea.  CMU is
big on compatibility.  (If you had thousands of students using
thousands of programs and only tens of people to update them, I
imagine you would be big on compatibility too.)
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690)
UUCP:	seismo!mimsy!chris	ARPA/CSNet:	chris@mimsy.umd.edu