prevents surprising effects post-installation on serial-only x86 systems
(e.g. bhyve) where the kernel messages will appear, rc scripts will run,
and then there will be no login prompt and you will be locked out of the
system.
Thanks to Devin Teske and Peter Grehan for ideas and testing. With this
patch, it may also be possible to unify all or most of the machine-specific
ttys files.
When we had utmp(5), we had to list all the psuedo-terminals in ttys(5)
to make ttyslot(3) function properly. Now that pututxline(3) deals with
slot allocation internally (not based on TTY names), we don't need to
list all the TTYs on the system in ttys(5) to make user accounting work
properly.
This patch removes all the entries from the /etc/ttys files, but also
the pts(4) entries that were appended implicitly, which was added in
r154838.
vt220 will not work better. Even though it probably will remove warnings
about unknown terminal types, a cons25 emulator is not compatible with
vt220 at all.
Even though I increased the amount of pts(4) entries in /etc/ttys some
time ago, I didn't realize back then those entries shouldn't have been
there in the first place.
I just looked at the getttyent() source code and it turns out when you
call setttyent(), it walks through /dev/pts and looks for the device
with the highest number. After you receive EOF's from getttyent(), it
makes up entries for pts(4) devices.
This means that adding entries for pts(4) is somewhat harmful, because
if you now traverse the list, you get redundant entries, so just remove
them.
As discussed with Robert Watson on the src-committers list, it is safer
to keep at least some pty(4) entries in /etc/ttys, for applications that
roll their own PTY allocation routine and only search for BSD-style
PTY's.
This means we've now just toggled the amount of entries for pts(4) and
pty(4).
Requested by: rwatson
Because we now use pts(4)-style PTY's exclusively, there is no use for
these entries in /etc/ttys. Right now the pts(4) entries only go from 0
to 255. Because we're going to touch these files anyway, increase the
number to 511.
Discussed with: philip (ex-mentor)
The uart(4) driver has the advantage of supporting a wider variety of
hardware on a greater amount of platforms. This driver has already been
the standard on platforms such as ia64, powerpc and sparc64.
I've decided not to change anything on pc98. I'd rather let people from
the pc98 team look at this.
Approved by: philip (mentor), marcel
dcons(4): very simple console and gdb port driver
dcons_crom(4): FireWire attachment
dconschat(8): User interface to dcons
Tested with: i386, i386-PAE, and sparc64.
All functionality from the previous system has been preserved, and
users should still customize their system boot with the familiar
methods, rc.conf, rc.conf.local, rc.firewall, sysctl.conf, etc.
Users who have customized versions of scripts that have been removed
should take great care when upgrading, since the compatibility code
that used those old scripts has also been removed.
as the previous line already tells us we are in rc.${MACHINE_ARCH}. This
also allows more syscons configuration messages during startup to fit on
one line.
Reviewed by: dougb
* Put quotes around each line
* Single quotes for lines with no variable interpolation
* Double quotes if there is
* Capitalize each word that begins a line
* Make echo -n 'Doing foo:' ... echo '.' more of a standard
No functionality changes
kernel modules for ibcs2_enable and svr4_enable.
Don't rely on a shell script to do the neglibly less simple
job of loading a kernel module and running one command for
linux_enable.
These shell scripts are going away.
happen with a keyboard and monitor the console change was not as needed
in the i386 case as the Alpha case. IMO >50% of Alpha installs are using
a serial console, the change matching rev 1.7 should not be backed out.
more comprehensive. Previously, at least colour changes were not
applied to all virtual consoles.
PR: 15066
Reported by: Andy Farkas <andyf@speednet.com.au>
Submitted by: yokota
case instead of test where appropriate, since case allows case is a sh
builtin and (as a side-effect) allows case-insensitivity.
Changes discussed on freebsd-hackers.
Submitted by: Doug Barton <Doug@gorean.org>
