Re: [PATCH 0/7] TTY Keyboard Status Request

[Arseny Maslennikov <ar@cs.msu.ru>]

[-- Attachment #1: Type: text/plain, Size: 1652 bytes --]

On Sun, Jun 09, 2019 at 07:41:39PM +0200, Pavel Machek wrote:
> Hi!
> 
> > This patch series introduces TTY keyboard status request, a feature of
> > the n_tty line discipline that reserves a character in struct termios
> > (^T by default) and reacts to it by printing a short informational line
> > to the terminal and sending a Unix signal to the tty's foreground
> > process group. The processes may, in response to the signal, output a
> > textual description of what they're doing.
> > 
> > The feature has been present in a similar form at least in
> > Free/Open/NetBSD; it would be nice to have something like this in Linux
> > as well. There is an LKML thread[1] where users have previously
> > expressed the rationale for this.
> > 
> > The current implementation does not break existing kernel API in any
> > way, since, fortunately, all the architectures supported by the kernel
> > happen to have at least 1 free byte in the termios control character
> > array.
> 
> I like the idea... I was often wondering "how long will this dd take". (And in
> case of dd, SIGUSR1 does the job).
> 
> I assume this will off by default, so that applications using ^T today will not
> get surprise signals?
> 									Pavel

If any of isig, icanon and iexten is disabled on the tty, the signal is
not sent.

Any application that wants to handle raw terminal input events itself,
e.g. vim, mutt, libreadline, anything ncurses-based, etc., has to turn
off the tty's cooked mode, i.e. at least icanon. This means those
applications are unaffected.

The commit messages of individual patches try to explain this in detail.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]