Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site masscomp.UUCP
Path: utzoo!watmath!clyde!masscomp!trb
From: trb@masscomp.UUCP
Newsgroups: net.unix-wizards
Subject: Re: Terminal paging in the kernel
Message-ID: <216@masscomp.UUCP>
Date: Tue, 6-Mar-84 10:42:19 EST
Article-I.D.: masscomp.216
Posted: Tue Mar  6 10:42:19 1984
Date-Received: Wed, 7-Mar-84 07:29:10 EST
References: <6841@cca.UUCP> <690@ihuxx.UUCP>
Organization: MASSCOMP, Littleton, MA
Lines: 29

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

Yea, and *we* make assumptions about what disk drives are.  In a piece
of common code.  That it's 24 sectors around and maybe 80 tracks
deep.  Is there not a trend toward larger disks, or controllers with
built-in addressing smarts?  We change the kernel code again and
again...

I like having terminal paging in the kernel.  I think that the folks
who don't want it there could be characterized as UNIX prudes, the
Jerry Foulwells of system software.  They have a right to their
opinion as long as they stay out of my bedroom and don't terrorize my
children.

Dennis Ritchie has done work with the notion of stacked line
disciplines, which are sort of an extension of the UNIX pipe
philosophy to lower level I/O line interfaces.  This would be the
place for terminal paging if AT&T (or someone else) would ever make it
available.  This stacking notion should be used for disk drivers too,
so that we could layer per-device notions on top of a generic disk
driver.

	Andy Tannenbaum   Masscomp Inc  Westford MA   (617) 692-6200 x274