Terminal paging in the kernel (OS structure & stdio buffering)

[Geoffrey Collyer]

[non-null first line]
	From: barmar at 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