Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!rutgers!uwvax!mcvoy From: mcvoy@uwvax.UUCP Newsgroups: comp.sources.wanted,comp.unix.wizards,comp.unix.questions Subject: Re: UUCP Port Turnaround (==> Unix Kernel hacks) Message-ID: <3233@rsch.WISC.EDU> Date: Mon, 16-Feb-87 13:06:43 EST Article-I.D.: rsch.3233 Posted: Mon Feb 16 13:06:43 1987 Date-Received: Tue, 17-Feb-87 06:04:34 EST References: <171@ndmath.UUCP> <4090@nsc.nsc.com> <166@piaget.UUCP> <43099@beno.seismo.CSS.GOV> <2388@homxb.UUCP> <13355@sun.uucp> Reply-To: mcvoy@rsch.WISC.EDU (Lawrence W. McVoy) Organization: U of Wisconsin CS Dept Lines: 85 Summary: Hold on, Guy Xref: watmath comp.sources.wanted:531 comp.unix.wizards:981 comp.unix.questions:1051 In article <13355@sun.uucp> guy@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@rsch.wisc.edu, {seismo, topaz, harvard, ihnp4, etc}!uwvax!mcvoy "They're coming soon! Quad-stated guru-gates!"