Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!henry
From: henry@utzoo.UUCP (Henry Spencer)
Newsgroups: comp.sources.wanted,comp.unix.wizards,comp.unix.questions
Subject: Re: UUCP Port Turnaround
Message-ID: <7717@utzoo.UUCP>
Date: Sat, 28-Feb-87 21:56:53 EST
Article-I.D.: utzoo.7717
Posted: Sat Feb 28 21:56:53 1987
Date-Received: Sat, 28-Feb-87 21:56:53 EST
References: <171@ndmath.UUCP>
Organization: U of Toronto Zoology
Lines: 27
Keywords: uucp

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

The question is not whether it's necessary to put things in the kernel --
if one is willing to accept disastrous performance degradation, almost
nothing *needs* to go in the kernel -- but whether it is appropriate to
put a specific thing into the kernel.  Coordinating use of resources is
*the* most central role of the kernel.  Virtually everything the kernel
does could be done in library functions if sharing wasn't an issue.  So
coordinating shared use of serial ports is an eminently reasonable thing
to put in the kernel, if you can make it simple and workable.  You can.

Speaking as someone who is strongly biased in favor of small, simple
kernels, and whose hatred of many aspects of the "Berkeley philosophy"
is widely known, doing dialin/out coordination in the kernel is the right
thing to do.  Making it work with the existing tty handler code isn't the
easiest thing in the world, but the resulting user interface is so simple
and beautiful that we're willing to live with slightly buggy machinery until
we get around to fixing it.

As testimony to the simplicity and appeal of the technique, it was invented
independently in at least four different places.
-- 
Legalize			Henry Spencer @ U of Toronto Zoology
freedom!			{allegra,ihnp4,decvax,pyramid}!utzoo!henry