Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!cbatt!ucbvax!jade!eris!mwm From: mwm@eris.UUCP Newsgroups: comp.sources.wanted,comp.unix.wizards,comp.unix.questions Subject: Re: UUCP Port Turnaround (==> Unix Kernel hacks) Message-ID: <2549@jade.BERKELEY.EDU> Date: Mon, 16-Feb-87 17:09:20 EST Article-I.D.: jade.2549 Posted: Mon Feb 16 17:09:20 1987 Date-Received: Thu, 19-Feb-87 05:36:49 EST References: <171@ndmath.UUCP> <4090@nsc.nsc.com> <166@piaget.UUCP> Sender: usenet@jade.BERKELEY.EDU Reply-To: mwm@eris.BERKELEY.EDU (Mike (No one lives forever.) Meyer) Organization: Missionaria Phonibalonica Lines: 64 Xref: watmath comp.sources.wanted:554 comp.unix.wizards:1004 comp.unix.questions:1079 In article <3233@rsch.WISC.EDU> mcvoy@rsch.WISC.EDU (Lawrence W. McVoy) writes: >In article <13355@sun.uucp> guy@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).