History log of /freebsd-10.0-release/etc/etc.sparc64/
Revision Date Author Comments
(<<< Hide modified files)
(Show modified files >>>)
259065 07-Dec-2013 gjb

- Copy stable/10 (r259064) to releng/10.0 as part of the
10.0-RELEASE cycle.
- Update __FreeBSD_version [1]
- Set branch name to -RC1

[1] 10.0-CURRENT __FreeBSD_version value ended at '55', so
start releng/10.0 at '100' so the branch is started with
a value ending in zero.

Approved by: re (implicit)
Sponsored by: The FreeBSD Foundation

256281 10-Oct-2013 gjb

Copy head (r256279) to stable/10 as part of the 10.0-RELEASE cycle.

Approved by: re (implicit)
Sponsored by: The FreeBSD Foundation


220154 30-Mar-2011 ed

Remove the reference to pseudo-terminals from the description.

Pseudo-terminals are no longer listed in this file, since the utmpx
implementation doesn't depend on ttyslot().


203068 27-Jan-2010 ed

Remove pseudo-terminals from ttys(5).

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.


199243 13-Nov-2009 ed

Switch the default terminal emulation style to xterm for most platforms.

Right now syscons(4) uses a cons25-style terminal emulator. The
disadvantages of that are:

- Little compatibility with embedded devices with serial interfaces.
- Bad bandwidth efficiency, mainly because of the lack of scrolling
regions.
- A very hard transition path to support for modern character sets like
UTF-8.

Our terminal emulation library, libteken, has been supporting
xterm-style terminal emulation for months, so flip the switch and make
everyone use an xterm-style console driver.

I still have to enable this on i386. Right now pc98 and i386 share the
same /etc/ttys file. I'm not going to switch pc98, because it uses its
own Kanji-capable cons25 emulator.

IMPORTANT: What to do if things go wrong (i.e. graphical artifacts):

- Run the application inside script(1), try to reduce the problem and
send me the log file.
- In the mean time, you can run `vidcontrol -T cons25' and `export
TERM=cons25' so you can run applications the same way you did before.
You can also build your kernel with `options TEKEN_CONS25' to make all
virtual terminals use the cons25 emulator by default.

Discussed on: current@


194218 14-Jun-2009 ed

Remove the note about using vt220, which makes no sense at all.

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.


188535 12-Feb-2009 ed

Remove pts(4) entries from /etc/ttys.

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.


182104 24-Aug-2008 ed

Restore 256 pty(4) entries.

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


182058 23-Aug-2008 ed

Remove old BSD-style entries from /etc/ttys and increase pts(4) to 512.

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)


173755 19-Nov-2007 jhb

Bump up the number of ttys supported by pty(4) to 512 by making use of
[pt]ty[lmnoLMNO][0-9a-v].

MFC after: 3 days
Reviewed by: rwatson


173638 15-Nov-2007 rwatson

Add ttys lines for pts/0-pts/255.

MFC after: 3 days


170088 29-May-2007 dougb

Remove more vestiges of /usr/X11R6, but leave mtree for portmgr.


158026 25-Apr-2006 marius

Remove last vestiges of sab(4).


155323 04-Feb-2006 marius

Enable getty(8) on ttyu2 by default in order to get machines that use a
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


147276 10-Jun-2005 marius

- In preparation to turning syscons(4) etc. on by default in the sparc64
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.


143311 09-Mar-2005 obrien

Be consistent about the serial line terminal type.
CVS ----------------------------------------------------------------------


141034 30-Jan-2005 marcel

Start gettys on ttyu0 and ttyu1 instead of ttya and ttyz0 now that
uart(4) is the default driver.

MFC after: 2 weeks


138369 04-Dec-2004 marius

Catch up with the new device name of sab(4). The entries for tty[a,b]
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.


136108 04-Oct-2004 kensmith

With the fixes to getty handling of non-existent devices a default
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


121468 24-Oct-2003 simokawa

Add dumb console driver and related bits.

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.


119972 11-Sep-2003 jake

Changed the ttyd entries to ttyu, which correspond to the device nodes
created by uart(4).


114492 02-May-2003 dougb

Per previous announcement, remove the old version of the rc system.

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.


112984 02-Apr-2003 ru

Make disktab(5) MI (repo-copied from etc.i386/disktab).


109921 27-Jan-2003 jake

Change ofwcons to use the output-device property from the firmware for the
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


101329 04-Aug-2002 jake

Add example entries for ttya and ttyb (sab).


94929 17-Apr-2002 gerald

Mention that terminal type vt220 will work better if one needs
interoperability with other systems like Solaris or GNU/Linux.

PR: 33810
Approved by: obrien


89029 07-Jan-2002 jhb

Populate etc.sparc64:
- 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)