cvs commit: src/etc/etc.mips ttys

[Peter Wemm]

On Mon, May 5, 2008 at 2:06 PM, Bernd Walter <ticso at cicely12.cicely.de> wrote:
>
> On Mon, May 05, 2008 at 08:08:23AM -0600, M. Warner Losh wrote:
>  > In message: <200805050949.27063.jhb at freebsd.org>
>  >             John Baldwin <jhb at FreeBSD.org> writes:
>  > : On Monday 05 May 2008 04:07:22 am Poul-Henning Kamp wrote:
>  > : > In message <481EB19B.3000201 at freebsd.org>, Colin Percival writes:
>  > : > >Poul-Henning Kamp wrote:
>  > : > >> In message <200805050535.m455ZmI1030493 at repoman.freebsd.org>, Warner
>  > : > >> Losh write
>  > : > >>
>  > : > >> s:
>  > : > >>>  Added files:
>  > : > >>>    etc/etc.mips         ttys
>  > : > >>>  Log:
>  > : > >>>  Mips ttys file.  Copied from i386 version with removal of the vga
>  > : > >>>  entries.
>  > : > >>
>  > : > >> We should really replace this file with a script that generates it
>  > : > >> from a set of sensible parameters at build-time.
>  > : > >
>  > : > >Yes please -- kmacy might have worked around this, but at one point this
>  > : > >was the only non-kernel file which needed to be different for Xen builds.
>  > : >
>  > : > And for anyone looking at this, there is also a task to eliminate the
>  > : > pty devices in this file, the reason why they are there has to do with
>  > : > the introduction of the really weird notion of "remote logins" back in
>  > : > the early 1980'ies, we really could do better.
>  > :
>  > : Err, I thought it was because utmp still uses the line index in /etc/ttys so
>  > : ptys have to be listed in /etc/ttys to get an index.  I haven't looked at
>  > : utmpx, but it might be nice if we had a utmp format that 1) didn't limit
>  > : usernames to 16 chars, and 2) stored the name of the tty rather than a dev_t.
>  > : 2) is what I think has broken 'w -M /var/crash/vmcore.X' since 5.x.
>
>  3) don't limit hostnames to 16 chars.
>  These days it is even to short for logging IPs as fallback, since inet6
>  IPs can be longer than the field.
>  I've often seen truncated inet6 IPs.

Uh oh.  This thread again..  Oh well, at least it only happens every
few years instead of every 6 months.

I'm a SVR4.0 refugee, which had a pair of files.. utmp and utmpx.
That caused an untold amount of pain and suffering.  Some programs
would write to utmp in the old format, so the library code had magic
fixup code that would detect utmp getting spammed and would 'expand'
it by copying over the records to utmpx format.

The things that would go wrong were almost endless.  And.. they had a
library API to try and encapsulate it all with.  We don't even have
that - we have "int ttyslot(char *ttyname)" to tell us the record
number to lseek() to for utmp.  ie: every single application that can
update utmp has the size of the utmp records compiled in, and it has
the knowledge that the /etc/ttys file (via ttyslot()) defines the seek
index.

Every single xterm-like program out there (and there are a lot) has
this knowledge compiled in, along with things like screen, snmp
agents, and so on.

Based on my previous experience with trying to make a backwards
compatible system and the misery it causes, and that we have the
benefit of hindsight, I'd suggest that if we fix it, we make a clean
break and be done with it.

If we wanted to do it right, I'd be suggesting that we make a clean
break and keep the information in one place, and in a file format that
isn't sensitive to fixed record sizes.  ie: utmp.db (like pwd.db and
friends).  Wrap it in a SuS/unix/linux/svr4/-ish {get|put}utxxx() set
of APIs and kill off the fixed record size utmp file.  We can get
creative with wrappers or whatever, but we can probably provide a
variable length record API as well.

SuS/XSI/etc version:
http://www.opengroup.org/onlinepubs/009695399/functions/endutxent.html
Linux version (utmpx versions are aliases for regular utmp):
http://linux.die.net/man/3/getutent

logwtmp() and friends could do wtmp.db.

Note that I'm not talking about run levels or anything like that.
Just suggesting that if we're going to change the file format, then we
make a clean break and use an open ended flexible format.
-- 
Peter Wemm - peter at wemm.org; peter at FreeBSD.org; peter at yahoo-inc.com
"All of this is for nothing if we don't go to the stars" - JMS/B5
"If Java had true garbage collection, most programs would delete
themselves upon execution." -- Robert Sewell