From owner-svn-src-head@FreeBSD.ORG Tue Mar 11 02:23:41 2014 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 67BFEE69; Tue, 11 Mar 2014 02:23:41 +0000 (UTC) Received: from mail105.syd.optusnet.com.au (mail105.syd.optusnet.com.au [211.29.132.249]) by mx1.freebsd.org (Postfix) with ESMTP id 0E9424E; Tue, 11 Mar 2014 02:23:40 +0000 (UTC) Received: from c122-106-147-133.carlnfd1.nsw.optusnet.com.au (c122-106-147-133.carlnfd1.nsw.optusnet.com.au [122.106.147.133]) by mail105.syd.optusnet.com.au (Postfix) with ESMTPS id 8DC61104428D; Tue, 11 Mar 2014 13:23:38 +1100 (EST) Date: Tue, 11 Mar 2014 13:23:38 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Marcel Moolenaar Subject: Re: svn commit: r262957 - in head/etc: etc.arm etc.ia64 etc.mips etc.powerpc etc.sparc64 In-Reply-To: <201403092106.s29L6M3D056313@svn.freebsd.org> Message-ID: <20140311120707.A1147@besplex.bde.org> References: <201403092106.s29L6M3D056313@svn.freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.1 cv=fbeUlSgF c=1 sm=1 tr=0 a=7NqvjVvQucbO2RlWB8PEog==:117 a=PO7r1zJSAAAA:8 a=1LetlUZaercA:10 a=kj9zAlcOel0A:10 a=JzwRw_2MAAAA:8 a=eVQHVEMfozF3_0W9SmMA:9 a=CjuIK1q_8ugA:10 Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2014 02:23:41 -0000 On Sun, 9 Mar 2014, Marcel Moolenaar wrote: > Log: > Change the terminal type/class for enabled serial lines to 3wire. This > allows us to change the uart(4) driver to not hardcode specific line > settings for the serial console. /etc/ttys and /etc/gettytab are still stupid configuration methods. They hard-code settings in a different way. You can edit them, but this is painful across many machines, even if all the configurations are the same (but differ from the defaults). They hard-code too many settings. /etc/rc.d/serial is a bit hackish, but works especially well for consoles. > A terminal type of 3wire makes sure the console still works when no DCD > signal is present, which preserves behviour. When it is known that the > terminal server (or DCE in general) provides DCD, a terminal type/class > of std can be used. This has the effect of being logged out when one > disconnects from the console -- improving security overall. Now you default to 3wire instead of defaulting to modem control. All my local systems have cables giving full modem control. This is useful even for consoles -- it gives the disconnection that you mention. > Likewise, when uart(4) does not fixate the baudrate, one can change > the terminal type/class to set a specific baudrate. An operator can use > this to change the console speed mid-flight, without needing a reboot. > Of course it helps in this respect if and when the firmware can be > configured from the OS. It should still lock the speed and everything, to make it not too easy to break kernel console output. Without locking, anyone with write access can change the speed. That is normally root:wheel for callin devices and uucp:dialer for callout devices. Bad terminal programs like cu have a hard-coded internal speed. If you forget this and type cu -l... without a speed, then this breaks kernel console output if the speed isn't locked and cu's default differs from the actual speed. The settings used for booting should work then and be very hard to change. sio uses the following mechanisms which make the speed a little too hard to change and everything else much too hard (impossible) to change: - the driver locks critical boot-time settings (moved to tty.c in my version of not-very-current, so that it works for all drivers) - there is a sysctl to change the speed. I never approved of this and am still waiting for even the style bugs in it to be fixed - applications can change the settings after unlocking the locked ones, but this only affects high-level consoles. The sysctl must be used to change the speed for low-level consoles, and nothing else can be changed for low-level consoles. In particular, certain operations involving DTR are forced for low-level consoles. - low-level console i/o switches dynamically to the almost-fixed kernel parameters. Bad things happen when these parameters differ from the high-level (termios) parameters, but usually the only to the high-level i/o. E.g.: - if you allow an application to set bad parameters, then application i/o doesn't work, but kernel i/o keeps working - if you trace through parameter setting using a debugger, with the debugger i/o on the same device as the console, then debugger i/o doesn't break when the transient state becomes unsuitable for i/o. Worse things happen with the kernel parameters differ from the ones needed to work with the other side, but that is rare -- the parameters should have worked for booting, and to change them you should carefully change both sides together or in small steps that can easily be backed out of. > Modified: head/etc/etc.arm/ttys > ============================================================================== > --- head/etc/etc.arm/ttys Sun Mar 9 21:02:23 2014 (r262956) > +++ head/etc/etc.arm/ttys Sun Mar 9 21:06:22 2014 (r262957) > @@ -41,7 +41,7 @@ ttyv7 "/usr/libexec/getty Pc" xterm off > #ttyv8 "/usr/local/bin/xdm -nodaemon" xterm off secure > # Serial terminals > # The 'dialup' keyword identifies dialin lines to login, fingerd etc. > -ttyu0 "/usr/libexec/getty std.9600" vt100 on secure > +ttyu0 "/usr/libexec/getty 3wire" vt100 on secure > ttyu1 "/usr/libexec/getty std.9600" dialup off secure > ttyu2 "/usr/libexec/getty std.9600" dialup off secure > ttyu3 "/usr/libexec/getty std.9600" dialup off secure > The stupidness of the /etc/ttys and /etc/gettytab configuration methods starts with hard-coding the console. It is usually on device 0, but not always. For me it is always on d0, not u0, and I always have to edit these files to change the speed to 115200. > Modified: head/etc/etc.ia64/ttys The stupidness of the configuration methods continues with not-quite- duplicating the ttys files to hold minor differences depending on ${ARCH}. Local differences are likely to be much larger (but not as large as 20-30 years ago with larger numbers of ttys on modems). > ============================================================================== > --- head/etc/etc.ia64/ttys Sun Mar 9 21:02:23 2014 (r262956) > +++ head/etc/etc.ia64/ttys Sun Mar 9 21:06:22 2014 (r262957) > @@ -41,8 +41,8 @@ ttyv7 "/usr/libexec/getty Pc" xterm off > ttyv8 "/usr/local/bin/xdm -nodaemon" xterm off secure > # Serial terminals. The 'dialup' keyword identifies dialin lines to login, > # fingerd etc. > -ttyu0 "/usr/libexec/getty std.9600" vt100 on secure > -ttyu1 "/usr/libexec/getty std.9600" vt100 on secure > +ttyu0 "/usr/libexec/getty 3wire" vt100 on secure > +ttyu1 "/usr/libexec/getty 3wire" vt100 on secure > ttyu2 "/usr/libexec/getty std.9600" dialup off secure > ttyu3 "/usr/libexec/getty std.9600" dialup off secure > # Dumb console > Here you have 2 3wires instead of 1. This is not an arch-dependent difference. > Modified: head/etc/etc.mips/ttys > ============================================================================== > --- head/etc/etc.mips/ttys Sun Mar 9 21:02:23 2014 (r262956) > +++ head/etc/etc.mips/ttys Sun Mar 9 21:06:22 2014 (r262957) > @@ -30,7 +30,7 @@ > console none unknown off secure > # Serial terminals > # The 'dialup' keyword identifies dialin lines to login, fingerd etc. > -ttyu0 "/usr/libexec/getty std.115200" dialup on secure > +ttyu0 "/usr/libexec/getty 3wire" vt100 on secure > ttyu1 "/usr/libexec/getty std.115200" dialup off secure > ttyu2 "/usr/libexec/getty std.115200" dialup off secure > ttyu3 "/usr/libexec/getty std.115200" dialup off secure This is a much larger non-arch-dependent change. ttyu0 went from dialup to vt100. It is a bug for it to be so different from other arches, but maybe someone has no serial consoles and depends on it being dialup. > Modified: head/etc/etc.powerpc/ttys > ... > Modified: head/etc/etc.sparc64/ttys > ============================================================================== > --- head/etc/etc.sparc64/ttys Sun Mar 9 21:02:23 2014 (r262956) > +++ head/etc/etc.sparc64/ttys Sun Mar 9 21:06:22 2014 (r262957) > @@ -46,9 +46,9 @@ ttyv8 "/usr/local/bin/xdm -nodaemon" xte > # Serial terminals > # The 'dialup' keyword identifies dialin lines to login, fingerd etc. > # uart(4) > -ttyu0 "/usr/libexec/getty std.9600" vt100 on secure > -ttyu1 "/usr/libexec/getty std.9600" vt100 on secure > -ttyu2 "/usr/libexec/getty std.9600" vt100 on secure > +ttyu0 "/usr/libexec/getty 3wire" vt100 on secure > +ttyu1 "/usr/libexec/getty 3wire" vt100 on secure > +ttyu2 "/usr/libexec/getty 3wire" vt100 on secure > ttyu3 "/usr/libexec/getty std.9600" vt100 off secure > # Dumb console > dcons "/usr/libexec/getty std.9600" vt100 off secure Now 3 3wires instead of 1 or 2. No dialups at all. You didn't change amd64 or i386 at all. I now see the pattern for the 3wires: you mostly changed all non-dialups to 3wire. The number of dialups is arch-dependent for no good reason. amd64 and i386 have silly differences between themselves and the above: - amd64 has u0 std.11500 xterm on secure (surely broken to default to on?) - i386 has u0 std.9600 dialup off secure - amd64 and i386 are closer to having maximal dialups than others - amd64 and i386 have more things on than others. I think this is because the ttyv* lines essentially hard-code syscons and this is least wrong on x86. Bruce