Re: Opinions on removing /proc/tty?

["Albert Cahalan" <acahalan@gmail.com>]

On 7/9/06, Ray Lee <madrabbit@gmail.com> wrote:
> On 7/9/06, Albert Cahalan <acahalan@gmail.com> wrote:
> > In any case, I'm NOT running a udevinfo program or linking
> > to a screwball library. Random failures are not OK.
>
> Complete agreement, but it seems like there's a third option here.
> We're talking about nothing more complicated than a table lookup here.
> Having a `udevinfo` invocation would indeed be overkill (and slower
> than just stating the entire /dev hierarchy, I'm sure), but
> Greg's/Jon's point that udev is the original authoritative source of
> the data remains.
>
> A simple solution would be for udev to just maintain a list in a flat
> file (e.g., /dev/.mappings) that could be read (very quickly) by ps
> upon startup. This could be yet another strategy somewhere in your
> list of heroic efforts to derive a /dev/ node :-).
>
> Having anyone other than udev try to maintain that mappings cache file
> is doomed to failure, as you already noted.

BSD just uses devname(3) in libc, which asks the kernel via
the kern.devname sysctl. So, /proc/sys/kern/devname for us.
This is essentially what /proc/tty/drivers is today, except
that FreeBSD standardized on a fully functional devfs.

Solaris uses _ttyname_dev(dev_t,buf,bufsize), also in libc.
This is horribly slow, involving a recursive search of
directories listed in the /etc/ttysrch file. The interface
is nice though. You get: ttyname, ttyname_r, _ttyname_dev.

Note that our glibc is often defective, not always upgraded,
and not even the only C library. I won't be relying on it
even if _ttyname_dev() or devname() gets implemented.

If you insist on bringing back the dead though...

I already have code, probably written in 1996 by Charles Blake.
Use /etc/psdevtab for the filename.

File format:

There are 16 tty major numbers (as of the Linux 1.1 kernel,
or thereabouts) with 256 minors each, and the names are 8
characters long. That makes for a 32 KiB file; procps will
verify the length. Major numbers are to be stored in the
following order:

2,3,4,5,19,20,22,23,24,25,32,33,46,47,48,49

The structure is thus like this:

char psdevtab[16][256][8]

Names should be zero-padded, not zero-terminated.

(seriously, a binary file with a tree structure is best)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/