Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!lll-winken!elroy.jpl.nasa.gov!swrinde!zaphod.mps.ohio-state.edu!rpi!ispd-newsserver!ism.isc.com!ico!rcd
From: rcd@ico.isc.com (Dick Dunn)
Newsgroups: comp.unix.sysv386
Subject: Re: (...) Can we make it smaller?
Summary: complexity
Message-ID: <1991Apr24.192651.388@ico.isc.com>
Date: 24 Apr 91 19:26:51 GMT
References: <7395@spdcc.SPDCC.COM>
Organization: Interactive Systems Corporation, Boulder, CO
Lines: 51

In article <7395@spdcc.SPDCC.COM>, rbraun@spdcc.COM (Rich Braun) writes:

> Reading this thread, I can't help but to wonder:  why worry about
> kernel size, these days?  I've long been one to complain about the fact
> that software seems to get larger in direct proportion to the decrease
> in memory costs, and often slower due to its increasing complexity, but
> in the case of a reasonably well-performing O/S with lots of features,
> why worry so much about kernel size?

First, I think one can argue whether the kernels we're seeing can really be
characterized as "reasonably well-performing".  My own belief is that we've
become inured to the performance costs of kernel bloat, and rapidly in-
creasing hardware speed has covered for us...but I think we're wasting a
lot of the hardware's potential.  This has hurt UNIX in the PC world,
because it's been too big and slow to take advantage of the low-end
machines that would open large markets for it.

Second, I see the expansion of kernel code (not data) as a reliability/
correctness problem.  We keep pushing more and more crud into the code
which runs in privileged mode, and which manages the disks and all the data
structures critical to the integrity of your data.  Each time you add one
feature, you add a bunch of possibilities for wrong interactions (between
that new feature and all the existing ones).  It's very hard to "program
around" kernel bugs the way you can with applications.  The more code you
get in the kernel, the harder it is for anyone to understand it, hence the
more likely new code will be implemented without full awareness of what's
going on around it.  And, let's be frank, the more kernel code you're
getting, the lower the average quality of the programmer writing it.

Rich is right--the memory cost is not that big an issue (any more).  But I
do think that performance and correctness are serious concerns, and getting
more serious every day.

Let's add another: software cost.  It costs a lot of money to add code to
the kernel.  The writing, debugging, testing, etc. is more expensive than
app code.  You're paying for it, and you're not going to see costs drop as
long as everybody's gone feature-mad-hog-wild making major additions in
each release.

> Add another megabyte to the system and the problem will go away.  Seems
> a fairly simple and economical solution.  Even at 1-2Mb, kernels remain
> significantly smaller than most applications...

I assume you're talking about X applications?  I don't have *any* apps on
my machine which come within a factor of 2 of the kernel size, except in
/usr/bin/X11 (and only a few there).  Most of what I use is in the range
of 10-30 Kb of code.  (That strikes me as very backwards--that the fattest
chunk of code I see is the one that is most critical to the system.)
-- 
Dick Dunn     rcd@ico.isc.com -or- ico!rcd       Boulder, CO   (303)449-2870
   ...While you were reading this, Motif grew by another kilobyte.