lkml.org 
[lkml]   [2019]   [Jun]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 0/7] TTY Keyboard Status Request
On Sun, Jun 09, 2019 at 09:51:32PM +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?
> >
> > If any of isig, icanon and iexten is disabled on the tty, the signal is
> > not sent.
>
> As expected.
>
> > 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.
>
> Agreed, those are unaffected.
>
> But if I have an application doing read() from console (without
> manipulating tty), am I going to get surprise signal when user types
> ^T?
>
> Pavel

As of now, that application will indeed receive a signal that is
guaranteed to be ignored by default.

This is similar to SIGWINCH, which is default-ignored as well: if the
terminal width/height changes (like when a terminal emulator window is
resized), its foreground pgrp gets a surprise signal as well, and the
processes that don't care about WINCH (and thus have default
disposition) do not get confused.
E.g. 'strace cat' demonstrates this quite clearly.

[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2019-06-09 22:57    [W:0.073 / U:0.552 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site