Terminal paging in the kernel

[Barry Margolin]

    If there were a way to obtain this information for each 
    terminal WITHOUT hardcoding it into the kernel, this portion of the 
    paging dispute would go away - but I don't see any way to do that.....

Sure there is - the user tells the kernal how many lines and columns
there are.  I have seen references to "stty page 24".  You could
simplify it by allowing "stty type vt100"; stty would look vt100 up in
termcap to find out the number of lines, and then make the appropriate
system call.  This way you don't need the type table in the kernal, just
the ability to make use of the information in the table.  In some cases
you can even do better than requiring the user to use stty: many
terminals have a recognizable answerback, so when it dials up Unix can
send an ENQ and see if it recognizes the answerback.

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

So, either put up or shut up.  The fact is that someone has made very
minor kernal modifications to add a very useful feature.
-- 
			Barry Margolin
			ARPA: barmar at MIT-Multics
			UUCP: ..!genrad!mit-eddie!barmar