From owner-freebsd-current@freebsd.org Fri Jun 30 19:06:03 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 432F2D98366 for ; Fri, 30 Jun 2017 19:06:03 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1b.ore.mailhop.org (outbound1b.ore.mailhop.org [54.200.247.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 272E078F8B for ; Fri, 30 Jun 2017 19:06:02 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 24dbb7e1-5dc7-11e7-bfce-afd4446ba3af X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound1.ore.mailhop.org (Halon) with ESMTPSA id 24dbb7e1-5dc7-11e7-bfce-afd4446ba3af; Fri, 30 Jun 2017 19:05:56 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id v5UJ5sP8001714; Fri, 30 Jun 2017 13:05:54 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1498849554.86861.65.camel@freebsd.org> Subject: Re: about history:) From: Ian Lepore To: Toomas Soome , freebsd-current Date: Fri, 30 Jun 2017 13:05:54 -0600 In-Reply-To: <426EB37B-F468-4D81-BB7F-0EC1485BAD8C@me.com> References: <426EB37B-F468-4D81-BB7F-0EC1485BAD8C@me.com> Content-Type: text/plain; charset="windows-1251" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jun 2017 19:06:03 -0000 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/.init or .lock file could set the speed to 0). -- Ian