Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!cs.utexas.edu!uunet!nuchat!sugar!ficc!peter
From: peter@ficc.uu.net (Peter da Silva)
Newsgroups: comp.unix.wizards
Subject: Re: New (GNU) kernels--what I think
Keywords: UNIX progress; controversy
Message-ID: <4484@ficc.uu.net>
Date: 10 Jun 89 01:56:25 GMT
References: <2501@gandalf.UUCP> <4366@ficc.uu.net> <2514@gandalf.UUCP>
Organization: Xenix Support
Lines: 24

In article <2514@gandalf.UUCP>, ml@gandalf.UUCP (Marcus Leech) writes:
> I didn't call for the removal of I/O from the kernel. I just said that it
>   (the I/O kernel subsystem) should be decoupled enough from the rest of
>   the kernel to make I/O hardware less-capable of crashing the system.

> No.  History buffers of a user-selectable arbitrary size don't belong in
>   the kernel, which I why I suggested the callback-like interrupt mechanism.
>   Other mechanisms, as I said, might suggest themselves.

We have a communication problem.

You have this idea that there is a place for a huge monolithic kernel in a
new operating system. More useful is a real kernel and a set of cooperating
lightweight processes. This would make the question of what you put in the
kernel and what you make a process moot.

But even in a monolithic kernel, allocating 10K or so for history buffers
isn't going to make a gnats fart worth of difference when you take into
account the megabyte of disk buffers i the typical modern UNIX system.
-- 
Peter da Silva, Xenix Support, Ferranti International Controls Corporation.

Business: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180.
Personal: ...!texbell!sugar!peter, peter@sugar.hackercorp.com.