Terminal paging in the kernel

[Dave Ihnat, Chicago, IL]

In response to Steve Zimmerman's defense of page mode in the kernel
driver:

Steve, you've answered a number of objections cleanly and
convincingly.  I would like to take this opportunity to point out two
important items:

	- ANY time anyone talks about adding *anything* to the Unix(Tm)
	  kernel, it's most emphatically a subject for protracted
	  discussion.  One of the most important things Unix forced on an
	  operating system was excision of 'features' that weren't
	  critically required in the kernel, e.g., record maintenance in
	  the file system).  Any move to add something to the kernel is a
	  move in the other direction; thus, whether they yelped for an
	  intelligent, reasoned reason or from dogmatism, those who questioned
	  your move were *RIGHT* to do so.  Their, and your, following
	  discussions justify or invalidate the change.

	-When considering such modifications to the kernel, you have to
	 consider if the benefits, as analyzed by either you or the user
	 community, is a real benefit because of the quality of your
	 change, or because of the shortcomings of Unix!

Why did I bring up such self-obvious questions?  Simply because I
still believe you're wrong to put such code in the kernel.  Why?
First, the kernel should only contain code that manages critical
system resources--and the paging of your terminal isn't a critical
system resource.  (Why?  Because the system is already managing access
to your terminal, which *is* a critical resource.  Why is raw/cooked
in the kernel, if paging shouldn't be?  To be honest, I'm not totally
certain that it belongs there!)

So, what are the reasons you *shouldn't* put such things in the 
kernel?  Because of just exactly the type of thing you mention--the
arguments that came up when full-screen editors began to proliferate.
*You* are making assumptions about what a terminal is, in a piece of
common code--that it's 24 lines long, and maybe 80 characters wide.
Are there other types of terminals?  Is there not a trend toward
larger screens, or bitmapped, variable font terminals??  Maybe...so
do you change the kernel code---again and again---or make this
performance-critical piece of code dependent on conditional tests,
external config files, etc.?  You mention the expense of all the
'more' processes--totally true!!  But doesn't this point to a need
for a better way of handling the use of identical processes on Unix,
rather than embedding more necessarily hardware- or assumption-dependent
code in the kernel??  (Like, maybe shared-text process slots for
system-wide shared text?  Or whatever.)

I guess the end of all of this is that it's horribly easy to add twenty or
thirty lines of code to the kernel to handle a special case.  But,
eventually, this way lies the large, over-specialized OS's of the
sixties and early seventies, such as OS-360 or even  GCOS-6.  We've
already got the problem of divergent Unix systems:  Berkeley and Bell.
(DON'T get me started on BSD...)  Let's not stumble BACK into the
errors made 20 years ago!

			Glad to accept mail on this topic,

				Dave Ihnat
				ihuxx!ignatz