Opinions on removing /proc/tty?

Opinions on removing /proc/tty?

[Jon Smirl]

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?

[root@jonsmirl tty]# cat drivers
/dev/tty             /dev/tty        5       0 system:/dev/tty
/dev/console         /dev/console    5       1 system:console
/dev/ptmx            /dev/ptmx       5       2 system
/dev/vc/0            /dev/vc/0       4       0 system:vtmaster
serial               /dev/ttyS       4 64-67 serial
pty_slave            /dev/pts      136 0-1048575 pty:slave
pty_master           /dev/ptm      128 0-1048575 pty:master
unknown              /dev/tty        4 1-63 console
[root@jonsmirl tty]#

[root@jonsmirl tty]# cat ldiscs
n_tty       0

-- 
Jon Smirl
jonsmirl@gmail.com

Re: Opinions on removing /proc/tty?

[Randy.Dunlap]

On Fri, 7 Jul 2006 22:56:51 -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?
> 
> [root@jonsmirl tty]# cat drivers
> /dev/tty             /dev/tty        5       0 system:/dev/tty
> /dev/console         /dev/console    5       1 system:console
> /dev/ptmx            /dev/ptmx       5       2 system
> /dev/vc/0            /dev/vc/0       4       0 system:vtmaster
> serial               /dev/ttyS       4 64-67 serial
> pty_slave            /dev/pts      136 0-1048575 pty:slave
> pty_master           /dev/ptm      128 0-1048575 pty:master
> unknown              /dev/tty        4 1-63 console
> [root@jonsmirl tty]#
> 
> [root@jonsmirl tty]# cat ldiscs
> n_tty       0

Hi,
I don't know how well this is an answer to your question,
but I would like to be able to find a list of registered "consoles,"
whether they be serial, usbserial, netconsole, lp, or whatever.
/proc/tty/drivers does that partially.

I have a patch that also does it in /proc/consoles:
  http://www.xenotime.net/linux/patches/consoles-list.patch
Is somewhere in /sys the right place to find a list of all consoles?

Thanks,
---
~Randy

Re: Opinions on removing /proc/tty?

[Mike Galbraith]

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.

	-Mike

Re: Opinions on removing /proc/tty?

[Jon Smirl]

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.

-- 
Jon Smirl
jonsmirl@gmail.com

Re: Opinions on removing /proc/tty?

[Alan Cox]

Ar Sad, 2006-07-08 am 10:12 -0400, ysgrifennodd Jon Smirl:
> > 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.

ps has some historical baggage in this area that probably ought to go,
but /proc/tty is used by various installers and management type apps so
shouldn't be going anywhere in a hurry.

Some of the stuff in there would be better in sysfs had sysfs been
around at the time. Other stuff like firmware loading in the serial
drivers would really benefit from a move to sysfs and hotplug events too

Re: Opinions on removing /proc/tty?

[Greg KH]

On Sat, Jul 08, 2006 at 10:12:36AM -0400, Jon Smirl wrote:
> 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.

So far no one has needed that kind of functionality from udevinfo.  It
should be easy to add if you need it, patches are always welcome :)

thanks,

greg k-h

Re: Opinions on removing /proc/tty?

[Jon Smirl]

On 7/8/06, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> Ar Sad, 2006-07-08 am 10:12 -0400, ysgrifennodd Jon Smirl:
> > > 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.
>
> ps has some historical baggage in this area that probably ought to go,
> but /proc/tty is used by various installers and management type apps so
> shouldn't be going anywhere in a hurry.
>
> Some of the stuff in there would be better in sysfs had sysfs been
> around at the time. Other stuff like firmware loading in the serial
> drivers would really benefit from a move to sysfs and hotplug events too

Then /proc/tty should take the same path as /proc/bus/usb. Make it
mountable and announce that it will disappear in two years.
Distributions will need to add a line to rc.sysinit like usb does, but
adding that line gives you a clue that /proc/tty is disappearing.

from rc.sysinit:
mount -n -t usbfs /proc/bus/usb /proc/bus/usb

I'll put together a patch making it mountable. Is there any specific
info that needs to be added to sysfs?

-- 
Jon Smirl
jonsmirl@gmail.com

Re: Opinions on removing /proc/tty?

[Russell King]

On Sat, Jul 08, 2006 at 12:20:06PM -0400, Jon Smirl wrote:
> I'll put together a patch making it mountable. Is there any specific
> info that needs to be added to sysfs?

Adding info to the sysfs side of tty devices is rather fraught (or was
last time I looked - I'd like to do exactly that with serial_core.)

Unfortunately, until it becomes easier (and maybe it recently has now
that tty_register_device returns the class device struct), /proc/tty
needs to stay.  But... I heard that Greg wants to remove struct
class_device...

So until this area gets sorted out I'm in no hurry to make any
changes in this area.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

Re: Opinions on removing /proc/tty?

[Randy.Dunlap]

On Sat, 8 Jul 2006 01:56:02 -0400 Jon Smirl wrote:

> On 7/8/06, Randy.Dunlap <rdunlap@xenotime.net> wrote:
> > I don't know how well this is an answer to your question,
> > but I would like to be able to find a list of registered "consoles,"
> > whether they be serial, usbserial, netconsole, lp, or whatever.
> > /proc/tty/drivers does that partially.
> 
> Console is an overloaded word. Do you want to know where it is legal
> to send system log output to, or do you want to know where you can log
> in from? There was a thread earlier that talked a little about
> controlling this.

I have a working definition:
I want to see a list of drivers that have called register_console().

> > I have a patch that also does it in /proc/consoles:
> >   http://www.xenotime.net/linux/patches/consoles-list.patch
> > Is somewhere in /sys the right place to find a list of all consoles?
> 
> /sys is the right place for this info but a class does not exist for it yet.

I want a list of registered consoles.  How would I express that in /sys ?

> Your patch isn't printing correctly. It is supposed to write the
> output to seq_file, not use printk.

Pray tell where does it call printk()?

> I get one entry on my system:
> 0: tty      x:W:U flags: print consoledev enabled
> 
> I would have thought that I would see entries for network, serial, and
> syslog too.

Yes for network and serial or usbserial.  I wouldn't expect syslog
(based on my working definition).

---
~Randy

Re: Opinions on removing /proc/tty?

[Randy.Dunlap]

On Sun, 9 Jul 2006 01:20:12 -0400 Jon Smirl wrote:

> On 7/9/06, Randy.Dunlap <rdunlap@xenotime.net> wrote:
> > On Sat, 8 Jul 2006 01:56:02 -0400 Jon Smirl wrote:
> >
> > > On 7/8/06, Randy.Dunlap <rdunlap@xenotime.net> wrote:
> > > > I don't know how well this is an answer to your question,
> > > > but I would like to be able to find a list of registered "consoles,"
> > > > whether they be serial, usbserial, netconsole, lp, or whatever.
> > > > /proc/tty/drivers does that partially.
> > >
> > > Console is an overloaded word. Do you want to know where it is legal
> > > to send system log output to, or do you want to know where you can log
> > > in from? There was a thread earlier that talked a little about
> > > controlling this.
> >
> > I have a working definition:
> > I want to see a list of drivers that have called register_console().
> >
> > > > I have a patch that also does it in /proc/consoles:
> > > >   http://www.xenotime.net/linux/patches/consoles-list.patch
> > > > Is somewhere in /sys the right place to find a list of all consoles?
> > >
> > > /sys is the right place for this info but a class does not exist for it yet.
> >
> > I want a list of registered consoles.  How would I express that in /sys ?
> 
> You could make the list appear as an attribute in
> /sys/class/tty/console. You will need to all a little sysfs code after
> the console tty device is created.
> 
> >
> > > Your patch isn't printing correctly. It is supposed to write the
> > > output to seq_file, not use printk.
> >
> > Pray tell where does it call printk()?
> >
> 
> +	for (con = console_drivers; con; con = con->next)
> +		printk("%d: %-8s %c:%c:%c flags:%s%s%s%s%s\n",
> +			con->index, con->name,
> +			con->read ? 'R' : 'x',

Ack, don't know how I missed that.

---
~Randy

Re: Opinions on removing /proc/tty?

[Antonino A. Daplas]

Jon Smirl wrote:
> On 7/9/06, Randy.Dunlap <rdunlap@xenotime.net> wrote:
>> On Sat, 8 Jul 2006 01:56:02 -0400 Jon Smirl wrote:
>>
>> > On 7/8/06, Randy.Dunlap <rdunlap@xenotime.net> wrote:
>> > > I don't know how well this is an answer to your question,
>> > > but I would like to be able to find a list of registered "consoles,"
>> > > whether they be serial, usbserial, netconsole, lp, or whatever.
>> > > /proc/tty/drivers does that partially.
>> >
>> > Console is an overloaded word. Do you want to know where it is legal
>> > to send system log output to, or do you want to know where you can log
>> > in from? There was a thread earlier that talked a little about
>> > controlling this.
>>
>> I have a working definition:
>> I want to see a list of drivers that have called register_console().
>>
>> > > I have a patch that also does it in /proc/consoles:
>> > >   http://www.xenotime.net/linux/patches/consoles-list.patch
>> > > Is somewhere in /sys the right place to find a list of all consoles?
>> >
>> > /sys is the right place for this info but a class does not exist for
>> it yet.
>>
>> I want a list of registered consoles.  How would I express that in /sys ?
> 
> You could make the list appear as an attribute in
> /sys/class/tty/console. You will need to all a little sysfs code after
> the console tty device is created.
> 

That would violate the one file, one value rule and GregKH will drop
it like a hot potato.

A better solution is to have /sys/class/console.

Tony

Re: Opinions on removing /proc/tty?

[Randy.Dunlap]

On Sun, 9 Jul 2006 09:45:06 -0400 Jon Smirl wrote:

> On 7/9/06, Antonino A. Daplas <adaplas@gmail.com> wrote:
> > Jon Smirl wrote:
> > > On 7/9/06, Randy.Dunlap <rdunlap@xenotime.net> wrote:
> > >> On Sat, 8 Jul 2006 01:56:02 -0400 Jon Smirl wrote:
> > >>
> > >> > On 7/8/06, Randy.Dunlap <rdunlap@xenotime.net> wrote:
> > >> > > I don't know how well this is an answer to your question,
> > >> > > but I would like to be able to find a list of registered "consoles,"
> > >> > > whether they be serial, usbserial, netconsole, lp, or whatever.
> > >> > > /proc/tty/drivers does that partially.
> > >> >
> > >> > Console is an overloaded word. Do you want to know where it is legal
> > >> > to send system log output to, or do you want to know where you can log
> > >> > in from? There was a thread earlier that talked a little about
> > >> > controlling this.
> > >>
> > >> I have a working definition:
> > >> I want to see a list of drivers that have called register_console().
> > >>
> > >> > > I have a patch that also does it in /proc/consoles:
> > >> > >   http://www.xenotime.net/linux/patches/consoles-list.patch
> > >> > > Is somewhere in /sys the right place to find a list of all consoles?
> > >> >
> > >> > /sys is the right place for this info but a class does not exist for
> > >> it yet.
> > >>
> > >> I want a list of registered consoles.  How would I express that in /sys ?
> > >
> > > You could make the list appear as an attribute in
> > > /sys/class/tty/console. You will need to all a little sysfs code after
> > > the console tty device is created.
> > >
> >
> > That would violate the one file, one value rule and GregKH will drop
> > it like a hot potato.
> >
> > A better solution is to have /sys/class/console.
> 
> The one value rule is for things that can be changed. For, example, I
> see no problem with using the graphics/modes attribute to see a list
> of legal modes, and then using graphics/mode to set or view the
> currently active mode. Why can't we have a read-only attribute that
> displays the list of available consoles?

We should be able to do that somewhere/somehow, but /sys does
not allow for it in one file, like Tony said.

---
~Randy

Re: Opinions on removing /proc/tty?

[Antonino A. Daplas]

Randy.Dunlap wrote:
> On Sun, 9 Jul 2006 09:45:06 -0400 Jon Smirl wrote:
> 
>> On 7/9/06, Antonino A. Daplas <adaplas@gmail.com> wrote:
>>> Jon Smirl wrote:
>>>> On 7/9/06, Randy.Dunlap <rdunlap@xenotime.net> wrote:
>>>>> On Sat, 8 Jul 2006 01:56:02 -0400 Jon Smirl wrote:
>>>>>
>>>>>> On 7/8/06, Randy.Dunlap <rdunlap@xenotime.net> wrote:
>>>>>>> I don't know how well this is an answer to your question,
>>>>>>> but I would like to be able to find a list of registered "consoles,"
>>>>>>> whether they be serial, usbserial, netconsole, lp, or whatever.
>>>>>>> /proc/tty/drivers does that partially.
>>>>>> Console is an overloaded word. Do you want to know where it is legal
>>>>>> to send system log output to, or do you want to know where you can log
>>>>>> in from? There was a thread earlier that talked a little about
>>>>>> controlling this.
>>>>> I have a working definition:
>>>>> I want to see a list of drivers that have called register_console().
>>>>>
>>>>>>> I have a patch that also does it in /proc/consoles:
>>>>>>>   http://www.xenotime.net/linux/patches/consoles-list.patch
>>>>>>> Is somewhere in /sys the right place to find a list of all consoles?
>>>>>> /sys is the right place for this info but a class does not exist for
>>>>> it yet.
>>>>>
>>>>> I want a list of registered consoles.  How would I express that in /sys ?
>>>> You could make the list appear as an attribute in
>>>> /sys/class/tty/console. You will need to all a little sysfs code after
>>>> the console tty device is created.
>>>>
>>> That would violate the one file, one value rule and GregKH will drop
>>> it like a hot potato.
>>>
>>> A better solution is to have /sys/class/console.
>> The one value rule is for things that can be changed.

No, it also applies to read-only attributes.

> For, example, I
>> see no problem with using the graphics/modes attribute to see a list
>> of legal modes, and then using graphics/mode to set or view the
>> currently active mode.

Yes, a lot of the fbdev attributes violate this rule. There's some
discussion in fbdev-devel list on how to overhaul this.
 
 Why can't we have a read-only attribute that
>> displays the list of available consoles?
> 
> We should be able to do that somewhere/somehow, but /sys does
> not allow for it in one file, like Tony said.

We can do it in debugfs, or do it like this in sysfs

/sys/class/console--- con0
                  :
                  --- con1
                  :
                  --- con2

Tony

Re: Opinions on removing /proc/tty?

[Greg KH]

On Sun, Jul 09, 2006 at 08:44:24PM -0400, Jon Smirl wrote:
> Much simpler solution:
> 
> cat /sys/class/graphics/fb0/modes
> mode_string
> mode_string
> mode_string
> mode_string
> mode_string
> mode_string
> mode_string
> mode_string
> mode_string
> mode_string
> mode_string
> ...

How do you handle the issue when this file overflows a PAGE_SIZE buffer?

> echo mode_string >/sys/class/graphics/fb0/mode

Yeah, that initially looks very simple, but again, it violates the sysfs
rules.  No matter how stupid you think they are, it still doesn't
matter...

If you really don't like it, make a fbfs, it's only about 200 lines of
code...

thanks,

greg k-h

Re: Opinions on removing /proc/tty?

[Greg KH]

On Sat, Jul 08, 2006 at 06:20:47PM +0100, Russell King wrote:
> On Sat, Jul 08, 2006 at 12:20:06PM -0400, Jon Smirl wrote:
> > I'll put together a patch making it mountable. Is there any specific
> > info that needs to be added to sysfs?
> 
> Adding info to the sysfs side of tty devices is rather fraught (or was
> last time I looked - I'd like to do exactly that with serial_core.)
> 
> Unfortunately, until it becomes easier (and maybe it recently has now
> that tty_register_device returns the class device struct), /proc/tty
> needs to stay.  But... I heard that Greg wants to remove struct
> class_device...

Yes I do want to remove it, but anything that you add to the
class_device will still work just fine, I'm not wanting to break
userspace tools anymore :)

And it should be pretty easy to do, now that we do return the
class_device that you need to have to add files to.

thanks,

greg k-h

Re: Opinions on removing /proc/tty?

[Greg KH]

On Tue, Jul 11, 2006 at 06:32:26PM -0400, Jon Smirl wrote:
> If you really want to stick with the one value model on the read-only
> attributes, how about a sysfs function that takes a variable and a
> string array of enum values. It creates a subdirectory named for the
> variable and makes attributes in the directory matching the names from
> the enum. The subdirectory avoids namespace collisions. The attributes
> are then managed like a set of radio buttons so that only one can be
> set non-zero at a time.  The driver read/write functions for the
> variable never knows this is going on, read/write just works with an
> index into the array.

That might be interesting.  Send a patch and I'll seriously consider it.

thanks,

greg k-h

Re: Opinions on removing /proc/tty?

[H. Peter Anvin]

Albert Cahalan wrote:
> 
> On any of Linux, MacOS, Solaris, NetBSD, OpenBSD:
> 
> $ ls /dev/tty /dev/ctty
> ls: /dev/ctty: No such file or directory
> /dev/tty
> 
> Lord only knows why FreeBSD has both.
> Unlike Linux, they don't supply a man page.
> On a Linux system, "man 4 tty" is useful.
> On a Solaris system, "man -s 7d tty" is useful.

On System V, /dev/ctty is the primary console device (meaning that 
unlike /dev/console, it cannot be redirected.)

	-hpa

Re: Opinions on removing /proc/tty?

[Albert Cahalan]

On 7/10/06, Jan Engelhardt <jengelh@linux01.gwdg.de> wrote:
> >> > Just do /proc/*/tty links and all will be good. This even
> >> > handles the case of two different names for the same dev_t.
> >> >
> >> Is this for the controlling tty? Then it should be ctty.
> >
> > Eeeew, an extra byte so it can look ugly.
> > What other special tty is there?
> >
> Any fd, for that matter.
>
> 00:09 shanghai:/dev/shm > ls -l /proc/$$/fd
> total 4
> dr-x------  2 jengelh users  0 Jul 11 00:16 .
> dr-xr-xr-x  5 jengelh root   0 Jul 11 00:04 ..
> lrwx------  1 jengelh users 64 Jul 11 00:16 0 -> /dev/pts/2
> lrwx------  1 jengelh users 64 Jul 11 00:16 1 -> /dev/pts/2
> lrwx------  1 jengelh users 64 Jul 11 00:16 2 -> /dev/pts/2
> lrwx------  1 jengelh users 64 Jul 11 00:16 255 -> /dev/pts/2
> and CTTY is /dev/tty1.
>
> So what would /proc/$$/tty - ambiguous name - point to, the normal (attached)
> or the ctty? Not to mention exotic, yet possible things

The tty is obviously one and the same as:

a. "tty" in the kernel's struct signal_struct
b. the "TTY" or "TT" reported by ps.
c. what "/dev/tty" refers to

Any other tty is not "the tty". Exactly one tty is special.

On any of Linux, MacOS, Solaris, NetBSD, OpenBSD:

$ ls /dev/tty /dev/ctty
ls: /dev/ctty: No such file or directory
/dev/tty

Lord only knows why FreeBSD has both.
Unlike Linux, they don't supply a man page.
On a Linux system, "man 4 tty" is useful.
On a Solaris system, "man -s 7d tty" is useful.

Re: Opinions on removing /proc/tty?

[Jan Engelhardt]

>> > Just do /proc/*/tty links and all will be good. This even
>> > handles the case of two different names for the same dev_t.
>> > 
>> Is this for the controlling tty? Then it should be ctty.
>
> Eeeew, an extra byte so it can look ugly.
> What other special tty is there?
>
Any fd, for that matter.

00:09 shanghai:/dev/shm > ls -l /proc/$$/fd
total 4
dr-x------  2 jengelh users  0 Jul 11 00:16 .
dr-xr-xr-x  5 jengelh root   0 Jul 11 00:04 ..
lrwx------  1 jengelh users 64 Jul 11 00:16 0 -> /dev/pts/2
lrwx------  1 jengelh users 64 Jul 11 00:16 1 -> /dev/pts/2
lrwx------  1 jengelh users 64 Jul 11 00:16 2 -> /dev/pts/2
lrwx------  1 jengelh users 64 Jul 11 00:16 255 -> /dev/pts/2
and CTTY is /dev/tty1.

So what would /proc/$$/tty - ambiguous name - point to, the normal (attached)
or the ctty? Not to mention exotic, yet possible things

00:09 shanghai:/dev/shm > ls -l /proc/$$/fd
total 4
dr-x------  2 jengelh users  0 Jul 11 00:16 .
dr-xr-xr-x  5 jengelh root   0 Jul 11 00:04 ..
lrwx------  1 jengelh users 64 Jul 11 00:16 0 -> /dev/pts/1
lrwx------  1 jengelh users 64 Jul 11 00:16 1 -> /dev/pts/2
lrwx------  1 jengelh users 64 Jul 11 00:16 2 -> /dev/pts/3
lrwx------  1 jengelh users 64 Jul 11 00:16 255 -> /dev/pts/4
and an even different ctty.

> It's always been "tty" in the kernel as far as I know.
> See "struct tty_struct *tty" in sched.h's struct signal_struct.
>
> Various "ps" programs have always used "TTY" or "TT".
> This makes "tt" more reasonable than "ctty".
>

Jan Engelhardt
-- 

Re: Opinions on removing /proc/tty?

[Albert Cahalan]

On 7/10/06, Jan Engelhardt <jengelh@linux01.gwdg.de> wrote:
> >
> > Just do /proc/*/tty links and all will be good. This even
> > handles the case of two different names for the same dev_t.
> >
> Is this for the controlling tty? Then it should be ctty.

Eeeew, an extra byte so it can look ugly.
What other special tty is there?

It's always been "tty" in the kernel as far as I know.
See "struct tty_struct *tty" in sched.h's struct signal_struct.

Various "ps" programs have always used "TTY" or "TT".
This makes "tt" more reasonable than "ctty".

Re: Opinions on removing /proc/tty?

[Jan Engelhardt]

>
> Just do /proc/*/tty links and all will be good. This even
> handles the case of two different names for the same dev_t.
>
Is this for the controlling tty? Then it should be ctty.


Jan Engelhardt
-- 

Re: Opinions on removing /proc/tty?

[Albert Cahalan]

On 7/9/06, Russell King <rmk+lkml@arm.linux.org.uk> wrote:

> So it basically breaks on 2.x kernels because (eg) you don't include major
> 204 as a tty major.  Plus, if you insist that there are only N tty major
> numbers, you break as soon as another tty major gets added.
>
> Try again.

I'm kidding of course. Putting the names in a file is crap.
This is what procps-1.x.xx did long ago. Everybody hated it.
You'll never handle chroot correctly.

Just do /proc/*/tty links and all will be good. This even
handles the case of two different names for the same dev_t.

If people seriously want to bring back the crap, then I can
design something tolerable. It would support mmap MAP_SHARED,
allowing live updates so that "top" can work nicely.

Re: Opinions on removing /proc/tty?

[Russell King]

On Sun, Jul 09, 2006 at 03:26:19PM -0400, Albert Cahalan wrote:
> 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]

So it basically breaks on 2.x kernels because (eg) you don't include major
204 as a tty major.  Plus, if you insist that there are only N tty major
numbers, you break as soon as another tty major gets added.

Try again.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core

Re: Opinions on removing /proc/tty?

[Albert Cahalan]

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)

Re: Opinions on removing /proc/tty?

[Ray Lee]

On 7/9/06, Ray Lee <madrabbit@gmail.com> wrote:
> 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.

And this could/should probably be an append-only file cleared out at
boot, so that the overhead of continually re-reading/re-writing the
file per device node on boot is removed. That'd slow things down for
sure.

Any reader just needs to know to read the whole file in, and either
construct a final lookup table in memory or scan backwards.

~r.

Re: Opinions on removing /proc/tty?

[Ray Lee]

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.

Ray

Re: Opinions on removing /proc/tty?

[Albert Cahalan]

On 7/9/06, Jon Smirl <jonsmirl@gmail.com> wrote:
> On 7/9/06, Albert Cahalan <acahalan@gmail.com> wrote:
> > 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 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)
> Doesn't existing the the current kernel.

Sure. It was planned, and there once was a half-written patch.
Right now, procps looks for Linux 2.7.0 before even trying.
(at the time, it was looking like the feature wouldn't make it
into the 2.6.xx series and that 2.7.xx would exist)

> > 2. /proc/tty/drivers
> This info can be wrong due to udev renames.  For example tty1 vs tty/1
> The info in /proc/tty/drivers describes hardware not processes, it
> belongs in sysfs, not /proc.

The only cost is a wasted stat() call to verify the name.
IMHO, using non-standard names is stupid anyway. The people
who do this are probably quite rare. As long as you stick to
the standard device names or devfs, this method is very fast.

(all of these methods will stat() the file to verify it)

> > 3. /proc/*/fd/2 symlink
> Working in the current kernel
>
> > 4. hard-coded guess
> This will be wrong because of udev renames. For example tty1 vs tty/1

That would be fucked up. You need a /dev/tty device.
You need that device even on non-Linux systems.
Also, your abbreviated tty names would start with "/", making
many tools interpret them as absolute paths.

See? Lots of badness happens if you mess with device names.

> > 5. /proc/*/fd/255 symlink
> Working in the current kernel
>
> > 6. "?"
> Always good
>
> > 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.
>
> This is what udev does, it maintains the mapping between devices and
> names. Udevinfo is how you query the database. /etc/udev is where you
> control how the device numbers are mapped into names.

You'd just better not choose screwball names.

> Now we have a good example of the impact of pushing something (udev)
> into user space and not shipping the binary as part of the kernel
> tree. What is the API for converting a device node number to a name?

I suggest using devfs.  :-)  The /proc/tty/drivers names
are correct on devfs systems.

We have a Documentation/devices.txt file in the kernel source.
Nearly all of the time, this alone should do the job.

Note that procps needs to handle a tty that udev doesn't
know about, even on a system running udev. It's best to
have everything in /dev with devices.txt names, but somebody
might create a chroot environment somewhere else.
Only the symlinks in /proc can provide this.

In any case, I'm NOT running a udevinfo program or linking
to a screwball library. Random failures are not OK.

Re: Opinions on removing /proc/tty?

[Jon Smirl]

On 7/9/06, Albert Cahalan <acahalan@gmail.com> wrote:
> 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)
Doesn't existing the the current kernel.

> 2. /proc/tty/drivers
This info can be wrong due to udev renames.  For example tty1 vs tty/1
The info in /proc/tty/drivers describes hardware not processes, it
belongs in sysfs, not /proc.

> 3. /proc/*/fd/2 symlink
Working in the current kernel

> 4. hard-coded guess
This will be wrong because of udev renames. For example tty1 vs tty/1

> 5. /proc/*/fd/255 symlink
Working in the current kernel

> 6. "?"
Always good

> 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.

This is what udev does, it maintains the mapping between devices and
names. Udevinfo is how you query the database. /etc/udev is where you
control how the device numbers are mapped into names.

Now we have a good example of the impact of pushing something (udev)
into user space and not shipping the binary as part of the kernel
tree. What is the API for converting a device node number to a name?


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


-- 
Jon Smirl
jonsmirl@gmail.com

Re: Opinions on removing /proc/tty?

[Albert Cahalan]

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.