Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 exptools 1/6/84; site ihuxx.UUCP Path: utzoo!linus!vaxine!wjh12!genrad!decvax!harpo!ihnp4!ihuxx!ignatz From: ignatz@ihuxx.UUCP (Dave Ihnat, Chicago, IL) Newsgroups: net.unix-wizards Subject: Re: Terminal paging in the kernel Message-ID: <690@ihuxx.UUCP> Date: Tue, 6-Mar-84 04:30:32 EST Article-I.D.: ihuxx.690 Posted: Tue Mar 6 04:30:32 1984 Date-Received: Wed, 7-Mar-84 00:29:19 EST References: <6841@cca.UUCP> Organization: AT&T Bell Labs, Naperville, IL Lines: 60 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