Re: about history:)

On Fri, 2017-06-30 at 21:19 +0300, Toomas Soome wrote:
> hi!
> 
> there is an question about the tty line (canonical) mode — the
> internal implementation is using 2k buffer, but the related (public)
> constants are claiming buffer size about 255 chars. Why it is so -
> any hints about the background there?
> 
> #define MAX_CANON                 255   /* max bytes in term canon
> input line */
> #define MAX_INPUT                 255   /* max bytes in terminal
> input */
> 
> rgds,
> toomas

I don't have a direct answer to the question, but I do remember even
before the rewrite that gave us the current kern/tty.c and friends, the
old tty code had a #undef MAX_INPUT and then redefined it to 8K, with a
comment that the value in limits.h was "wrong".  From that I might
surmise that people over the years were afraid of changing values in
public header files that were handed down from the depths of unix
history and that might break something if changed.

I'm not sure MAX_CANON has a separate meaning from MAX_INPUT with the
current code.  I think both raw and canonical input use the same
buffering scheme that's based on a linked list of 128-byte chunks.  The
total size of all the chunks on the list isn't compile-time constant,
it's choosen at device open time to provide a buffer that is the
smaller of 64K or 2 seconds of incoming data.  (The code comment for
years said 0.2 seconds of data, and perhaps that was the intent, but I
corrected the comment rather than the code because .2s just isn't
enough for slow embedded systems).

You mention a 2k buffer... at the default input speed of 9600 baud the
2-seconds-size buffer is 1920 bytes.  Pseudo-ttys and video consoles
all seem to get this size.  I just noticed there's nothing in the
current code to prevent a pathologic buffer size of 0 if the input line
speed is set to 0 but the CREAD flag is set (I think maybe a
/dev/<serialdev>.init or .lock file could set the speed to 0).

-- Ian