RSC (Remote System Control) connected via uart2 as console working out
of the box. On machines that use uart2 to connect a keyboard and thus
the ttyu2 node doesn't exist this will trigger a warning from getty(8)
but cause no real harm.
MFC after: 1 week
GENERIC comment in ttyN.
- Add the name of the device driver creating the device nodes above the
respectives blocks so it's easier for user to find the right entry to
shut up warnings from getty(8). Replace 'Requires device 'uart' be
enabled.' with just 'uart(4)' as the former referred to a sparc64
GENERIC back when uart(4) wasn't enabled by default, yet.
- Turn off the getty(8) on screen as screen is created by ofw_console(4)
which is no longer enabled in the sparc64 GENERIC (and also only is a
last resort) to shut up warnings from getty(8) with the current GENERIC.
can't be removed as ofw_console(4) and zs(4) use them so one has to
live with some complaints about non-existent devices at boot time and
remove the respective entries locally for now.
install now complains about ttyu0/ttyu1 not existing at boot time.
Since users wanting the uart based devices as terminals will need
to do something special to get them anyway set it up so a default
config doesn't complain.
MFC after: 3 days
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.
name of the device that it creates. Update /etc/ttys accordingly.
An alias is created for the old name so that old /etc/ttys will continue to
work, but due to aliases being implemented as symlinks in devfs you cannot
login as root when using the alias device.
Discussed with: grehan
- The disktab was taken from etc.alpha.
- rc.sparc64 doesn't do anything right now.
- The ttys file has all the vty's commented out since we don't know how
those will work yet. Also, an entry is added for the Openfirmware
console device.
Submitted by: jake (partially)
