After Years In The BSDs, TTY Keyboard Status Request Feature Being Proposed For Linux

[phoronix]

Phoronix: After Years In The BSDs, TTY Keyboard Status Request Feature Being Proposed For Linux

For years most BSDs have supported a "TTY keyboard status request" to display status information at the terminal about the current foreground process and its CPU time consumed among other possible metrics. After being talked about in the past as a possible feature candidate, this functionality is now available in patch form to debate...

http://www.phoronix.com/scan.php?page=news_item&px=TTY-Keyboard-Status-Request-RFC

[Scheiker]

I hope this gets rejected, again, for being a terrible idea:

• It adds bloat to both the kernel and the user-land.
• Probably will make coreutils even more bloated with another signal to play with.
• Adds another useless feature to the tty driver, which should have died in the 80's in the advent of graphical monitors (seriously, the tty in unix was declared an ancient relic and removed from later operating systems, e.i. Plan 9, before Linux was even born).

Better solutions already exist that don't care about terminals and are program agnostic while no additional patches to kernel and user-land are needed.
Like Procfs:

• You can read file descriptor info in /proc/$pid/ and get the status of a running process without the need of signals.
• This allows network transparency because you are using a virtual file interface that can be exported over the network (everything should be file, no signals or ioctl()'s dammit!).
• An example of a convenient progress monitor that makes use of this: https://github.com/Xfennec/progress

There is also, of course, the well known 'pv' command that allows you to monitor the progress of a command by including it into a pipe.

If the main reason for adding this is, because BSD has it, then that is TERRIBLE reasoning.
BSD shouldn't have this either, it's bad design. Most of them haven't even implemented procfs and have to rely on signals and system calls for many basic things.
Procfs is a good design and is more UNIX-like so we should use it. We should be focused on
reducing the use of binary interfaces to the kernel and not adding to them.

Regardless, this will probably get added away.

[Bsdisbetter]

I hope this gets rejected, again, for being a terrible idea:

• It adds bloat to both the kernel and the user-land.
• Probably will make coreutils even more bloated with another signal to play with.
• Adds another useless feature to the tty driver, which should have died in the 80's in the advent of graphical monitors (seriously, the tty in unix was declared an ancient relic and removed from later operating systems, e.i. Plan 9, before Linux was even born).

Better solutions already exist that don't care about terminals and are program agnostic while no additional patches to kernel and user-land are needed.
Like Procfs:

• You can read file descriptor info in /proc/$pid/ and get the status of a running process without the need of signals.
• This allows network transparency because you are using a virtual file interface that can be exported over the network (everything should be file, no signals or ioctl()'s dammit!).
• An example of a convenient progress monitor that makes use of this: https://github.com/Xfennec/progress

There is also, of course, the well known 'pv' command that allows you to monitor the progress of a command by including it into a pipe.

If the main reason for adding this is, because BSD has it, then that is TERRIBLE reasoning.
BSD shouldn't have this either, it's bad design. Most of them haven't even implemented procfs and have to rely on signals and system calls for many basic things.
Procfs is a good design and is more UNIX-like so we should use it. We should be focused on
reducing the use of binary interfaces to the kernel and not adding to them.

Regardless, this will probably get added away.

Bloat? LOL. It's already in termios if it's posix. Siginfo handling is bloat? yeah, sure.

Notwithstanding that, linux user/kernel are two different beasts unlike bsd. It can be added to the kernel but who picks it up in userland? Gnu? Is it worthwhile in Linux, for some obviously. It seems to have been debated and then forgot about many years ago.

Also you have a narrow view of OS usage. One can imagine having only a single serial connection to a device, so running something and wondering what its progress/cpu time/usage is would be damn hard without Ctrl-T (even other non-unix os have it in some form). Does that magic-sysrq key allow this?

It is not bad design, not by a longshot. I won't bother debating unix-like as bsd is closer to that than linux. I can think of some bloatware that's the antithesis of 'unix-like'. Wanna guess what?

[Wojcian]

Bloat? LOL. It's already in termios if it's posix. Siginfo handling is bloat? yeah, sure.

SIGInfo isn't official POSIX signal.

It is not bad design, not by a longshot. I won't bother debating unix-like as bsd is closer to that than linux. I can think of some bloatware that's the antithesis of 'unix-like'. Wanna guess what?

If you mean systemD it's completely unrelated, because it doesn't affect kernel at all. Unix wasn't perfect and I prefer systemD approach than crap like sysV init etc.

[Guest]

Bloat? LOL. It's already in termios if it's posix. Siginfo handling is bloat? yeah, sure.

Notwithstanding that, linux user/kernel are two different beasts unlike bsd. It can be added to the kernel but who picks it up in userland? Gnu? Is it worthwhile in Linux, for some obviously. It seems to have been debated and then forgot about many years ago.

Also you have a narrow view of OS usage. One can imagine having only a single serial connection to a device, so running something and wondering what its progress/cpu time/usage is would be damn hard without Ctrl-T (even other non-unix os have it in some form). Does that magic-sysrq key allow this?

It is not bad design, not by a longshot. I won't bother debating unix-like as bsd is closer to that than linux. I can think of some bloatware that's the antithesis of 'unix-like'. Wanna guess what?

You can simply run top, which is already in POSIX to get that information. This signal is nothing but bloat, and should never be standardized nor implemented. It sounds like something that might've made sense back in the 60s before U*IX was really defined.

[k1e0x]

I hope this gets rejected, again, for being a terrible idea:

• It adds bloat to both the kernel and the user-land.
• Probably will make coreutils even more bloated with another signal to play with.
• Adds another useless feature to the tty driver, which should have died in the 80's in the advent of graphical monitors (seriously, the tty in unix was declared an ancient relic and removed from later operating systems, e.i. Plan 9, before Linux was even born).

Better solutions already exist that don't care about terminals and are program agnostic while no additional patches to kernel and user-land are needed.
Like Procfs:

• You can read file descriptor info in /proc/$pid/ and get the status of a running process without the need of signals.
• This allows network transparency because you are using a virtual file interface that can be exported over the network (everything should be file, no signals or ioctl()'s dammit!).
• An example of a convenient progress monitor that makes use of this: https://github.com/Xfennec/progress

There is also, of course, the well known 'pv' command that allows you to monitor the progress of a command by including it into a pipe.

If the main reason for adding this is, because BSD has it, then that is TERRIBLE reasoning.
BSD shouldn't have this either, it's bad design. Most of them haven't even implemented procfs and have to rely on signals and system calls for many basic things.
Procfs is a good design and is more UNIX-like so we should use it. We should be focused on
reducing the use of binary interfaces to the kernel and not adding to them.

Regardless, this will probably get added away.

Ancient bloat wars dubbed obsolete by Plan 9. (whats that?) Lets all use /proc and X!

Lol Linux.. hehe

[cthart]

Luckily none of you get to decide!

[aht0]

Lookie here, example of "Not Invented Here" syndrome, lol.

[DanaG]

Better solutions already exist that don't care about terminals and are program agnostic while no additional patches to kernel and user-land are needed.
Like Procfs:

• You can read file descriptor info in /proc/$pid/ and get the status of a running process without the need of signals.
• This allows network transparency because you are using a virtual file interface that can be exported over the network (everything should be file, no signals or ioctl()'s dammit!).
• An example of a convenient progress monitor that makes use of this: https://github.com/Xfennec/progress

There is also, of course, the well known 'pv' command that allows you to monitor the progress of a command by including it into a pipe.

Does top let you trigger an arbitrary signal handler in the foreground process upon pressing a key combination, without hijacking SIGINT, SIGTERM, or SIGQUIT? No. Good luck getting a python backtrace using top or procfs, as you can with a SIGINFO handler on BSD systems. PV won't help with that, either.

I've had *many* times where I wished Linux supported SIGINFO, so I could dump arbitrary info to stdout on demand.