Date: Tue, 11 Mar 2014 13:23:38 +1100 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Marcel Moolenaar <marcel@freebsd.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r262957 - in head/etc: etc.arm etc.ia64 etc.mips etc.powerpc etc.sparc64 Message-ID: <20140311120707.A1147@besplex.bde.org> In-Reply-To: <201403092106.s29L6M3D056313@svn.freebsd.org> References: <201403092106.s29L6M3D056313@svn.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140311120707.A1147>