geoff@utcsstat.UUCP (Geoffrey Collyer) (03/27/84)
This article doesn't seem to have made it very far the first time. Sorry if you are seeing this for the second time. From: barmar@mit-eddie.UUCP (Barry Margolin) Those of you who are against terminal paging in the kernal have not been very constructive. Anyone have any suggestions for a way to get this affect without doing it in the kernal? I am very sympathetic to those who believe that the kernal should only be used for the low-level device control that requires privileged instructions. Much of the discussion of pagination by the terminal driver lately seems to revolve around whether the kernel is an appropriate place for a terminal paginator or not. In a well-structured operating system, it isn't. Look at TUNIS or a number of operating systems more recent than UNIX*: in a well-structured operating system the kernel is small, a first-level interrupt handler and synchroniser with perhaps a smidgen of scheduling or memory management. In such a system, the UNIX common terminal code might be a terminal manager process. On UNIX, the kernel includes code that logically might be removed into separate processes under a different implementation. One would like the UNIX kernel to remain small, but let us remember that the UNIX kernel is conceptually a kernel (roughly speaking, the assembler code), device managers (the dev (a.k.a. io) directory), two levels of file system managers (flat inodes and directory trees), scheduler, swapper or pager, memory manager and some miscellany. I don't really want to put terminal pagination in the UNIX kernel, I want to put it in a terminal manager (which might even be, *gasp*, replacable by a user, in some implementations), but there isn't a terminal manager process in UNIX. However, the pipe mechanism doesn't provide enough functionality to do what we want. I just experimented with ncsh|more and discovered that I didn't see anything until I filled up a page or sent EOF (which was better than what happened when I tried csh|more which didn't even echo and didn't recognize ^D). In addition, there is no way to perform ioctl's on filters (I could be wrong - I am not that much of a wizard), and many programs use isatty, which will fail on pipes. I suppose it could be done with pseudo-tty's, but that will put a much larger burden on the system than one would want. I am aware that this has been beaten to death before in unix-wizards and have no wish to kindle another round. (I had hoped vainly that after the usual round of ad-hominem attacks, terminal pagination would be discussed only briefly. It is now almost two months since I posted the paginator.) I feel that isatty should have been named something like needcare (needs careful buffering) and returned true for pipes. The more serious problem is that many stdio implementations buffer output poorly to terminals and pipes (perhaps due to reliance on isatty). As previously noted, pipes were once used interactively. On v6, sh | pager worked as one would like. I think that I know how to make stdio correctly buffer output to terminals and pipes, but will refrain from further comment until I have tested my theory. So, either put up or shut up. The fact is that someone has made very minor kernal modifications to add a very useful feature. Agreed. The 44 lines of kernel terminal paginator that I posted seem insignificant next to the 1801 lines of our more.c. --- * UNIX is a trademark of AT&T Bell Laboratories, or something similar. Geoff Collyer, U. of Toronto