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