Re: Opinions on removing /proc/tty?

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

Jon Smirl writes:
> On 7/8/06, Mike Galbraith <efault@gmx.de> wrote:
>> On Fri, 2006-07-07 at 22:56 -0400, Jon Smirl wrote:

>>> Does anyone use the info in /proc/tty? The hard coded device
>>> names aren't compatible with udev's ability to rename things.
>>>
>>> There also doesn't appear to be any useful info in the drivers
>>> portion that isn't already available in sysfs. I can add some code
>>> to make a list of registered line disciplines appear in sysfs.
>>>
>>> Does anyone have a problem with deleting /proc/tty if
>>> ldisc enum support is added to sysfs?
>>
>> ps uses /proc/tty/drivers, so some coordination would be needed.
>
> Greg, I just looked at the source for ps and it has a bunch
> of fixed code for turning major/minor into /dev/name.  Isn't
> that something udevinfo should be doing? But looking at the
> help for udevinfo I don't see any way to turn a major/minor
> into /dev/name. The altermative seems to be search /dev
> looking for the right device node.

By far, the best thing for procps (ps, top, etc.) would
be /proc/*/tty links. Code that, give everybody a year
to upgrade, and then... maybe.

There is no way I'm going to have the procps run a "udevinfo"
program, and I very much dislike relying on oddball libraries.
Reliability and performance matter; this isn't some GNOME/KDE
thing that can break just because 1 of 200 libraries changed.

In order, the procps code tries:

1. /proc/*/tty symlink (effectively commented out)
2. /proc/tty/drivers
3. /proc/*/fd/2 symlink
4. hard-coded guess
5. /proc/*/fd/255 symlink
6. "?"

Long ago, procps would search /dev for the mapping. This was
too slow to be done directly when ps ran, so a binary file in
/etc was used to cache the data. Keeping that file updated
was a major problem.

BTW, cruft gets ripped out some time after Debian-obsolete no
longer supports the old kernels.