Date: Fri, 30 Jun 2017 13:05:54 -0600 From: Ian Lepore <ian@freebsd.org> To: Toomas Soome <tsoome@me.com>, freebsd-current <freebsd-current@freebsd.org> Subject: Re: about history:) Message-ID: <1498849554.86861.65.camel@freebsd.org> In-Reply-To: <426EB37B-F468-4D81-BB7F-0EC1485BAD8C@me.com> References: <426EB37B-F468-4D81-BB7F-0EC1485BAD8C@me.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1498849554.86861.65.camel>