2019-06-05 08:40:42

by Arseny Maslennikov

[permalink] [raw]
Subject: [PATCH 0/7] TTY Keyboard Status Request

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.

The series should cleanly apply to tty-next.

To thoroughly test these, one might need at least a patched stty among
other tools, so I've brought up a simple initrd generator[2] which can
be used to create a lightweight environment to boot up in a VM and to
fiddle with.

[1] https://lore.kernel.org/lkml/1415200663.3247743.187387481.75CE9317@webmail.messagingengine.com/
[2] https://github.com/porrided/tty-kb-status-userspace

Arseny Maslennikov (7):
signal.h: Define SIGINFO on all architectures
tty: termios: Reserve space for VSTATUS in .c_cc
n_tty: Send SIGINFO to fg pgrp on status request character
linux/signal.h: Ignore SIGINFO by default in new tasks
tty: Add NOKERNINFO lflag to termios
n_tty: ->ops->write: Cut core logic out to a separate function
n_tty: Provide an informational line on VSTATUS receipt

arch/alpha/include/asm/termios.h | 4 +-
arch/alpha/include/uapi/asm/termbits.h | 2 +
arch/arm/include/uapi/asm/signal.h | 1 +
arch/h8300/include/uapi/asm/signal.h | 1 +
arch/ia64/include/asm/termios.h | 4 +-
arch/ia64/include/uapi/asm/signal.h | 1 +
arch/ia64/include/uapi/asm/termbits.h | 2 +
arch/m68k/include/uapi/asm/signal.h | 1 +
arch/mips/include/asm/termios.h | 4 +-
arch/mips/include/uapi/asm/signal.h | 1 +
arch/mips/include/uapi/asm/termbits.h | 2 +
arch/parisc/include/asm/termios.h | 4 +-
arch/parisc/include/uapi/asm/signal.h | 1 +
arch/parisc/include/uapi/asm/termbits.h | 2 +
arch/powerpc/include/asm/termios.h | 4 +-
arch/powerpc/include/uapi/asm/signal.h | 1 +
arch/powerpc/include/uapi/asm/termbits.h | 2 +
arch/s390/include/asm/termios.h | 4 +-
arch/s390/include/uapi/asm/signal.h | 1 +
arch/sparc/include/asm/termios.h | 4 +-
arch/sparc/include/uapi/asm/signal.h | 2 +
arch/sparc/include/uapi/asm/termbits.h | 2 +
arch/x86/include/uapi/asm/signal.h | 1 +
arch/xtensa/include/uapi/asm/signal.h | 1 +
arch/xtensa/include/uapi/asm/termbits.h | 2 +
drivers/tty/Makefile | 3 +-
drivers/tty/n_tty.c | 69 ++++-
drivers/tty/n_tty_status.c | 363 +++++++++++++++++++++++
include/asm-generic/termios.h | 4 +-
include/linux/signal.h | 5 +-
include/linux/tty.h | 7 +-
include/uapi/asm-generic/signal.h | 1 +
include/uapi/asm-generic/termbits.h | 2 +
33 files changed, 475 insertions(+), 33 deletions(-)
create mode 100644 drivers/tty/n_tty_status.c

--
2.20.1


2019-06-05 08:41:04

by Arseny Maslennikov

[permalink] [raw]
Subject: [PATCH 5/7] tty: Add NOKERNINFO lflag to termios

Signed-off-by: Arseny Maslennikov <[email protected]>
---
arch/alpha/include/uapi/asm/termbits.h | 1 +
arch/ia64/include/uapi/asm/termbits.h | 1 +
arch/mips/include/uapi/asm/termbits.h | 1 +
arch/parisc/include/uapi/asm/termbits.h | 1 +
arch/powerpc/include/uapi/asm/termbits.h | 1 +
arch/sparc/include/uapi/asm/termbits.h | 1 +
arch/xtensa/include/uapi/asm/termbits.h | 1 +
include/linux/tty.h | 1 +
include/uapi/asm-generic/termbits.h | 1 +
9 files changed, 9 insertions(+)

diff --git a/arch/alpha/include/uapi/asm/termbits.h b/arch/alpha/include/uapi/asm/termbits.h
index bb895d467033..850dd8dc4c51 100644
--- a/arch/alpha/include/uapi/asm/termbits.h
+++ b/arch/alpha/include/uapi/asm/termbits.h
@@ -204,6 +204,7 @@ struct ktermios {
#define PENDIN 0x20000000
#define IEXTEN 0x00000400
#define EXTPROC 0x10000000
+#define NOKERNINFO 0x40000000

/* Values for the ACTION argument to `tcflow'. */
#define TCOOFF 0
diff --git a/arch/ia64/include/uapi/asm/termbits.h b/arch/ia64/include/uapi/asm/termbits.h
index 86898e4c5905..f777b99bc5ab 100644
--- a/arch/ia64/include/uapi/asm/termbits.h
+++ b/arch/ia64/include/uapi/asm/termbits.h
@@ -190,6 +190,7 @@ struct ktermios {
#define PENDIN 0040000
#define IEXTEN 0100000
#define EXTPROC 0200000
+#define NOKERNINFO 0400000

/* tcflow() and TCXONC use these */
#define TCOOFF 0
diff --git a/arch/mips/include/uapi/asm/termbits.h b/arch/mips/include/uapi/asm/termbits.h
index 3dd60924f0ef..2755cfd1497e 100644
--- a/arch/mips/include/uapi/asm/termbits.h
+++ b/arch/mips/include/uapi/asm/termbits.h
@@ -206,6 +206,7 @@ struct ktermios {
#define TOSTOP 0100000 /* Send SIGTTOU for background output. */
#define ITOSTOP TOSTOP
#define EXTPROC 0200000 /* External processing on pty */
+#define NOKERNINFO 0400000 /* Disable kernel output from VSTATUS. */

/* ioctl (fd, TIOCSERGETLSR, &result) where result may be as below */
#define TIOCSER_TEMT 0x01 /* Transmitter physically empty */
diff --git a/arch/parisc/include/uapi/asm/termbits.h b/arch/parisc/include/uapi/asm/termbits.h
index ecca3b7d0c66..c7ba145adf02 100644
--- a/arch/parisc/include/uapi/asm/termbits.h
+++ b/arch/parisc/include/uapi/asm/termbits.h
@@ -183,6 +183,7 @@ struct ktermios {
#define PENDIN 0040000
#define IEXTEN 0100000
#define EXTPROC 0200000
+#define NOKERNINFO 0400000

/* tcflow() and TCXONC use these */
#define TCOOFF 0
diff --git a/arch/powerpc/include/uapi/asm/termbits.h b/arch/powerpc/include/uapi/asm/termbits.h
index c85e98d75e76..79dbcc546217 100644
--- a/arch/powerpc/include/uapi/asm/termbits.h
+++ b/arch/powerpc/include/uapi/asm/termbits.h
@@ -192,6 +192,7 @@ struct ktermios {
#define PENDIN 0x20000000
#define IEXTEN 0x00000400
#define EXTPROC 0x10000000
+#define NOKERNINFO 0x40000000

/* Values for the ACTION argument to `tcflow'. */
#define TCOOFF 0
diff --git a/arch/sparc/include/uapi/asm/termbits.h b/arch/sparc/include/uapi/asm/termbits.h
index a1638c9cde8b..108c039ddefb 100644
--- a/arch/sparc/include/uapi/asm/termbits.h
+++ b/arch/sparc/include/uapi/asm/termbits.h
@@ -225,6 +225,7 @@ struct ktermios {
#define PENDIN 0x00004000
#define IEXTEN 0x00008000
#define EXTPROC 0x00010000
+#define NOKERNINFO 0x00020000

/* modem lines */
#define TIOCM_LE 0x001
diff --git a/arch/xtensa/include/uapi/asm/termbits.h b/arch/xtensa/include/uapi/asm/termbits.h
index 77969cb275b8..6155e1c81164 100644
--- a/arch/xtensa/include/uapi/asm/termbits.h
+++ b/arch/xtensa/include/uapi/asm/termbits.h
@@ -199,6 +199,7 @@ struct ktermios {
#define PENDIN 0040000
#define IEXTEN 0100000
#define EXTPROC 0200000
+#define NOKERNINFO 0400000

/* tcflow() and TCXONC use these */

diff --git a/include/linux/tty.h b/include/linux/tty.h
index 38d8ffe7f0e3..07189f18f93d 100644
--- a/include/linux/tty.h
+++ b/include/linux/tty.h
@@ -186,6 +186,7 @@ struct tty_bufhead {
#define L_PENDIN(tty) _L_FLAG((tty), PENDIN)
#define L_IEXTEN(tty) _L_FLAG((tty), IEXTEN)
#define L_EXTPROC(tty) _L_FLAG((tty), EXTPROC)
+#define L_NOKERNINFO(tty) _L_FLAG((tty), NOKERNINFO)

struct device;
struct signal_struct;
diff --git a/include/uapi/asm-generic/termbits.h b/include/uapi/asm-generic/termbits.h
index 11bb142ba844..6219803d6f4d 100644
--- a/include/uapi/asm-generic/termbits.h
+++ b/include/uapi/asm-generic/termbits.h
@@ -181,6 +181,7 @@ struct ktermios {
#define PENDIN 0040000
#define IEXTEN 0100000
#define EXTPROC 0200000
+#define NOKERNINFO 0400000

/* tcflow() and TCXONC use these */
#define TCOOFF 0
--
2.20.1

2019-06-05 08:41:16

by Arseny Maslennikov

[permalink] [raw]
Subject: [PATCH 1/7] signal.h: Define SIGINFO on all architectures

This complementary patch defines SIGINFO as a synonym for SIGPWR
on every architecture supported by the kernel.
The particular signal number chosen does not really matter and is only
required for the related tty functionality to work properly,
so if it does not suite expectations, any suggestions are warmly
welcome.

SIGPWR looks like a nice candidate for this role, because it is
defined on every supported arch; it is currently only used to inform
PID 1 of power failures, and daemons that care about low-level
events do not tend to have a controlling terminal.

However, on sparcs SIGPWR is a synonym for SIGLOST, a signal unique
to that architecture, with a narrow set of intended uses that do not
combine well with interactively requesting status.
SIGLOST is not used by any kernel code at the moment.
I'm not sure there is a more reasonable alternative right now.

Signed-off-by: Arseny Maslennikov <[email protected]>
---
arch/arm/include/uapi/asm/signal.h | 1 +
arch/h8300/include/uapi/asm/signal.h | 1 +
arch/ia64/include/uapi/asm/signal.h | 1 +
arch/m68k/include/uapi/asm/signal.h | 1 +
arch/mips/include/uapi/asm/signal.h | 1 +
arch/parisc/include/uapi/asm/signal.h | 1 +
arch/powerpc/include/uapi/asm/signal.h | 1 +
arch/s390/include/uapi/asm/signal.h | 1 +
arch/sparc/include/uapi/asm/signal.h | 2 ++
arch/x86/include/uapi/asm/signal.h | 1 +
arch/xtensa/include/uapi/asm/signal.h | 1 +
include/uapi/asm-generic/signal.h | 1 +
12 files changed, 13 insertions(+)

diff --git a/arch/arm/include/uapi/asm/signal.h b/arch/arm/include/uapi/asm/signal.h
index 9b4185ba4f8a..b80b53a17267 100644
--- a/arch/arm/include/uapi/asm/signal.h
+++ b/arch/arm/include/uapi/asm/signal.h
@@ -50,6 +50,7 @@ typedef unsigned long sigset_t;
#define SIGLOST 29
*/
#define SIGPWR 30
+#define SIGINFO SIGPWR
#define SIGSYS 31
#define SIGUNUSED 31

diff --git a/arch/h8300/include/uapi/asm/signal.h b/arch/h8300/include/uapi/asm/signal.h
index e15521037348..7a2b783af22b 100644
--- a/arch/h8300/include/uapi/asm/signal.h
+++ b/arch/h8300/include/uapi/asm/signal.h
@@ -50,6 +50,7 @@ typedef unsigned long sigset_t;
#define SIGLOST 29
*/
#define SIGPWR 30
+#define SIGINFO SIGPWR
#define SIGSYS 31
#define SIGUNUSED 31

diff --git a/arch/ia64/include/uapi/asm/signal.h b/arch/ia64/include/uapi/asm/signal.h
index aa98ff1b9e22..b4c98cb17165 100644
--- a/arch/ia64/include/uapi/asm/signal.h
+++ b/arch/ia64/include/uapi/asm/signal.h
@@ -45,6 +45,7 @@
#define SIGLOST 29
*/
#define SIGPWR 30
+#define SIGINFO SIGPWR
#define SIGSYS 31
/* signal 31 is no longer "unused", but the SIGUNUSED macro remains for backwards compatibility */
#define SIGUNUSED 31
diff --git a/arch/m68k/include/uapi/asm/signal.h b/arch/m68k/include/uapi/asm/signal.h
index 915cc755a184..a0b4e4108cb8 100644
--- a/arch/m68k/include/uapi/asm/signal.h
+++ b/arch/m68k/include/uapi/asm/signal.h
@@ -50,6 +50,7 @@ typedef unsigned long sigset_t;
#define SIGLOST 29
*/
#define SIGPWR 30
+#define SIGINFO SIGPWR
#define SIGSYS 31
#define SIGUNUSED 31

diff --git a/arch/mips/include/uapi/asm/signal.h b/arch/mips/include/uapi/asm/signal.h
index 53104b10aae2..975a6f0d3b0b 100644
--- a/arch/mips/include/uapi/asm/signal.h
+++ b/arch/mips/include/uapi/asm/signal.h
@@ -43,6 +43,7 @@ typedef unsigned long old_sigset_t; /* at least 32 bits */
#define SIGCHLD 18 /* Child status has changed (POSIX). */
#define SIGCLD SIGCHLD /* Same as SIGCHLD (System V). */
#define SIGPWR 19 /* Power failure restart (System V). */
+#define SIGINFO SIGPWR /* Keyboard status request (4.2 BSD). */
#define SIGWINCH 20 /* Window size change (4.3 BSD, Sun). */
#define SIGURG 21 /* Urgent condition on socket (4.2 BSD). */
#define SIGIO 22 /* I/O now possible (4.2 BSD). */
diff --git a/arch/parisc/include/uapi/asm/signal.h b/arch/parisc/include/uapi/asm/signal.h
index d38563a394f2..fe2e00d590ac 100644
--- a/arch/parisc/include/uapi/asm/signal.h
+++ b/arch/parisc/include/uapi/asm/signal.h
@@ -22,6 +22,7 @@
#define SIGUSR2 17
#define SIGCHLD 18
#define SIGPWR 19
+#define SIGINFO SIGPWR
#define SIGVTALRM 20
#define SIGPROF 21
#define SIGIO 22
diff --git a/arch/powerpc/include/uapi/asm/signal.h b/arch/powerpc/include/uapi/asm/signal.h
index 85b0a7aa43e7..e7f3885905b4 100644
--- a/arch/powerpc/include/uapi/asm/signal.h
+++ b/arch/powerpc/include/uapi/asm/signal.h
@@ -53,6 +53,7 @@ typedef struct {
#define SIGLOST 29
*/
#define SIGPWR 30
+#define SIGINFO SIGPWR
#define SIGSYS 31
#define SIGUNUSED 31

diff --git a/arch/s390/include/uapi/asm/signal.h b/arch/s390/include/uapi/asm/signal.h
index 9a14a611ed82..12ee62987971 100644
--- a/arch/s390/include/uapi/asm/signal.h
+++ b/arch/s390/include/uapi/asm/signal.h
@@ -58,6 +58,7 @@ typedef unsigned long sigset_t;
#define SIGLOST 29
*/
#define SIGPWR 30
+#define SIGINFO SIGPWR
#define SIGSYS 31
#define SIGUNUSED 31

diff --git a/arch/sparc/include/uapi/asm/signal.h b/arch/sparc/include/uapi/asm/signal.h
index ff9505923b9a..b655163198bb 100644
--- a/arch/sparc/include/uapi/asm/signal.h
+++ b/arch/sparc/include/uapi/asm/signal.h
@@ -71,6 +71,8 @@
#define SIGWINCH 28
#define SIGLOST 29
#define SIGPWR SIGLOST
+/* XXX: is it OK for SIGINFO to collide with LOST? */
+#define SIGINFO SIGPWR
#define SIGUSR1 30
#define SIGUSR2 31

diff --git a/arch/x86/include/uapi/asm/signal.h b/arch/x86/include/uapi/asm/signal.h
index e5745d593dc7..1539bb28826c 100644
--- a/arch/x86/include/uapi/asm/signal.h
+++ b/arch/x86/include/uapi/asm/signal.h
@@ -55,6 +55,7 @@ typedef unsigned long sigset_t;
#define SIGLOST 29
*/
#define SIGPWR 30
+#define SIGINFO SIGPWR
#define SIGSYS 31
#define SIGUNUSED 31

diff --git a/arch/xtensa/include/uapi/asm/signal.h b/arch/xtensa/include/uapi/asm/signal.h
index 005dec5bfde4..d644234305de 100644
--- a/arch/xtensa/include/uapi/asm/signal.h
+++ b/arch/xtensa/include/uapi/asm/signal.h
@@ -65,6 +65,7 @@ typedef struct {
#define SIGPOLL SIGIO
/* #define SIGLOST 29 */
#define SIGPWR 30
+#define SIGINFO SIGPWR
#define SIGSYS 31
#define SIGUNUSED 31

diff --git a/include/uapi/asm-generic/signal.h b/include/uapi/asm-generic/signal.h
index 5c716a952cbe..9f9a1db0d43c 100644
--- a/include/uapi/asm-generic/signal.h
+++ b/include/uapi/asm-generic/signal.h
@@ -43,6 +43,7 @@
#define SIGLOST 29
*/
#define SIGPWR 30
+#define SIGINFO SIGPWR
#define SIGSYS 31
#define SIGUNUSED 31

--
2.20.1

2019-06-05 08:42:02

by Arseny Maslennikov

[permalink] [raw]
Subject: [PATCH 4/7] linux/signal.h: Ignore SIGINFO by default in new tasks

This matches the behaviour of other Unix-like systems that have SIGINFO
and causes less harm to processes that do not install handlers for this
signal, making the keyboard status character non-fatal for them.

This is implemented with the assumption that SIGINFO is defined
to be equivalent to SIGPWR; still, there is no reason for PWR to
result in termination of the signal recipient anyway — it does not
indicate there is a fatal problem with the recipient's execution
context (like e.g. FPE/ILL do), and we have TERM/KILL for explicit
termination requests.

Signed-off-by: Arseny Maslennikov <[email protected]>
---
include/linux/signal.h | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/include/linux/signal.h b/include/linux/signal.h
index 9702016734b1..c365754ea647 100644
--- a/include/linux/signal.h
+++ b/include/linux/signal.h
@@ -360,7 +360,7 @@ extern bool unhandled_signal(struct task_struct *tsk, int sig);
* | SIGSYS/SIGUNUSED | coredump |
* | SIGSTKFLT | terminate |
* | SIGWINCH | ignore |
- * | SIGPWR | terminate |
+ * | SIGPWR | ignore |
* | SIGRTMIN-SIGRTMAX | terminate |
* +--------------------+------------------+
* | non-POSIX signal | default action |
@@ -411,7 +411,8 @@ extern bool unhandled_signal(struct task_struct *tsk, int sig);

#define SIG_KERNEL_IGNORE_MASK (\
rt_sigmask(SIGCONT) | rt_sigmask(SIGCHLD) | \
- rt_sigmask(SIGWINCH) | rt_sigmask(SIGURG) )
+ rt_sigmask(SIGWINCH) | rt_sigmask(SIGURG) | \
+ rt_sigmask(SIGINFO) )

#define SIG_SPECIFIC_SICODES_MASK (\
rt_sigmask(SIGILL) | rt_sigmask(SIGFPE) | \
--
2.20.1

2019-06-05 08:42:12

by Arseny Maslennikov

[permalink] [raw]
Subject: [PATCH 6/7] n_tty: ->ops->write: Cut core logic out to a separate function

To simplify internal re-use of the line discipline's write method,
we isolate the work it does to its own function.

Since in-kernel callers might not refer to the tty through a file,
the struct file* argument might make no sense, so we also stop
tty_io_nonblock() from dereferencing file too early, allowing
to pass NULL as the referring file here.

Signed-off-by: Arseny Maslennikov <[email protected]>
---
drivers/tty/n_tty.c | 33 ++++++++++++++++++++++-----------
include/linux/tty.h | 2 +-
2 files changed, 23 insertions(+), 12 deletions(-)

diff --git a/drivers/tty/n_tty.c b/drivers/tty/n_tty.c
index 29f33798a6cd..7d7d84adcffe 100644
--- a/drivers/tty/n_tty.c
+++ b/drivers/tty/n_tty.c
@@ -2309,22 +2309,15 @@ static ssize_t n_tty_read(struct tty_struct *tty, struct file *file,
* lock themselves)
*/

-static ssize_t n_tty_write(struct tty_struct *tty, struct file *file,
- const unsigned char *buf, size_t nr)
+static ssize_t do_n_tty_write(struct tty_struct *tty, struct file *file,
+ const unsigned char *buf, size_t nr)
{
const unsigned char *b = buf;
DEFINE_WAIT_FUNC(wait, woken_wake_function);
int c;
ssize_t retval = 0;

- /* Job control check -- must be done at start (POSIX.1 7.1.1.4). */
- if (L_TOSTOP(tty) && file->f_op->write != redirected_tty_write) {
- retval = tty_check_change(tty);
- if (retval)
- return retval;
- }
-
- down_read(&tty->termios_rwsem);
+ lockdep_assert_held_read(&tty->termios_rwsem);

/* Write out any echoed characters that are still pending */
process_echoes(tty);
@@ -2392,10 +2385,28 @@ static ssize_t n_tty_write(struct tty_struct *tty, struct file *file,
remove_wait_queue(&tty->write_wait, &wait);
if (nr && tty->fasync)
set_bit(TTY_DO_WRITE_WAKEUP, &tty->flags);
- up_read(&tty->termios_rwsem);
return (b - buf) ? b - buf : retval;
}

+static ssize_t n_tty_write(struct tty_struct *tty, struct file *file,
+ const unsigned char *buf, size_t nr)
+{
+ ssize_t retval = 0;
+
+ /* Job control check -- must be done at start (POSIX.1 7.1.1.4). */
+ if (L_TOSTOP(tty) && file->f_op->write != redirected_tty_write) {
+ retval = tty_check_change(tty);
+ if (retval)
+ return retval;
+ }
+
+ down_read(&tty->termios_rwsem);
+ retval = do_n_tty_write(tty, file, buf, nr);
+ up_read(&tty->termios_rwsem);
+
+ return retval;
+}
+
/**
* n_tty_poll - poll method for N_TTY
* @tty: terminal device
diff --git a/include/linux/tty.h b/include/linux/tty.h
index 07189f18f93d..ddb97704956d 100644
--- a/include/linux/tty.h
+++ b/include/linux/tty.h
@@ -388,7 +388,7 @@ static inline void tty_set_flow_change(struct tty_struct *tty, int val)

static inline bool tty_io_nonblock(struct tty_struct *tty, struct file *file)
{
- return file->f_flags & O_NONBLOCK ||
+ return (file && file->f_flags & O_NONBLOCK) ||
test_bit(TTY_LDISC_CHANGING, &tty->flags);
}

--
2.20.1

2019-06-05 08:42:35

by Arseny Maslennikov

[permalink] [raw]
Subject: [PATCH 3/7] n_tty: Send SIGINFO to fg pgrp on status request character

No kerninfo line is printed yet.

No existing implementation of this on any Unix-like system echoes
the status character; no existing implementation discards or flushes
pending input on VSTATUS receipt.

There are existing popular TUI applications (e. g. mutt) that only
turn off icanon and not iexten, but still do not expect any special
treatment of the status request character — thus we require all three:
isig, icanon and iexten to trigger this.

Signed-off-by: Arseny Maslennikov <[email protected]>
---
drivers/tty/n_tty.c | 15 +++++++++++++--
include/linux/tty.h | 1 +
2 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/drivers/tty/n_tty.c b/drivers/tty/n_tty.c
index f9c584244f72..29f33798a6cd 100644
--- a/drivers/tty/n_tty.c
+++ b/drivers/tty/n_tty.c
@@ -79,6 +79,10 @@
#define ECHO_BLOCK 256
#define ECHO_DISCARD_WATERMARK N_TTY_BUF_SIZE - (ECHO_BLOCK + 32)

+#define SIG_FLUSHING_MASK ( \
+ rt_sigmask(SIGINT) | rt_sigmask(SIGQUIT) | \
+ rt_sigmask(SIGTSTP) )
+#define SIG_FLUSHING(sig) ((1 << sig) & SIG_FLUSHING_MASK)

#undef N_TTY_TRACE
#ifdef N_TTY_TRACE
@@ -1122,7 +1126,7 @@ static void isig(int sig, struct tty_struct *tty)
{
struct n_tty_data *ldata = tty->disc_data;

- if (L_NOFLSH(tty)) {
+ if (L_NOFLSH(tty) || (!SIG_FLUSHING(sig))) {
/* signal only */
__isig(sig, tty);

@@ -1244,7 +1248,8 @@ n_tty_receive_signal_char(struct tty_struct *tty, int signal, unsigned char c)
if (I_IXON(tty))
start_tty(tty);
if (L_ECHO(tty)) {
- echo_char(c, tty);
+ if (c != STATUS_CHAR(tty))
+ echo_char(c, tty);
commit_echoes(tty);
} else
process_echoes(tty);
@@ -1294,6 +1299,9 @@ n_tty_receive_char_special(struct tty_struct *tty, unsigned char c)
} else if (c == SUSP_CHAR(tty)) {
n_tty_receive_signal_char(tty, SIGTSTP, c);
return 0;
+ } else if (c == STATUS_CHAR(tty)) {
+ n_tty_receive_signal_char(tty, SIGINFO, c);
+ return 0;
}
}

@@ -1848,6 +1856,9 @@ static void n_tty_set_termios(struct tty_struct *tty, struct ktermios *old)
set_bit(INTR_CHAR(tty), ldata->char_map);
set_bit(QUIT_CHAR(tty), ldata->char_map);
set_bit(SUSP_CHAR(tty), ldata->char_map);
+ if (L_ICANON(tty) && L_IEXTEN(tty)) {
+ set_bit(STATUS_CHAR(tty), ldata->char_map);
+ }
}
clear_bit(__DISABLED_CHAR, ldata->char_map);
ldata->raw = 0;
diff --git a/include/linux/tty.h b/include/linux/tty.h
index bfa4e2ee94a9..38d8ffe7f0e3 100644
--- a/include/linux/tty.h
+++ b/include/linux/tty.h
@@ -120,6 +120,7 @@ struct tty_bufhead {
#define WERASE_CHAR(tty) ((tty)->termios.c_cc[VWERASE])
#define LNEXT_CHAR(tty) ((tty)->termios.c_cc[VLNEXT])
#define EOL2_CHAR(tty) ((tty)->termios.c_cc[VEOL2])
+#define STATUS_CHAR(tty) ((tty)->termios.c_cc[VSTATUS])

#define _I_FLAG(tty, f) ((tty)->termios.c_iflag & (f))
#define _O_FLAG(tty, f) ((tty)->termios.c_oflag & (f))
--
2.20.1

2019-06-09 18:49:42

by Pavel Machek

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

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

2019-06-09 19:48:59

by Arseny Maslennikov

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

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.


Attachments:
(No filename) (1.61 kB)
signature.asc (849.00 B)
Download all attachments

2019-06-09 19:57:22

by Pavel Machek

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

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
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


Attachments:
(No filename) (1.90 kB)
signature.asc (188.00 B)
Digital signature
Download all attachments

2019-06-09 20:58:03

by Arseny Maslennikov

[permalink] [raw]
Subject: Re: [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.


Attachments:
(No filename) (2.37 kB)
signature.asc (849.00 B)
Download all attachments

2019-06-10 21:05:42

by Rob Landley

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

On 6/5/19 3:18 AM, Arseny Maslennikov wrote:
> 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.

I had a long twitter thread about this with some BSD developers,
https://twitter.com/landley/status/1127148250430152704
asked on the toybox list for opinions,
http://lists.landley.net/pipermail/toybox-landley.net/2019-May/010461.html
and became aware of this patch set when the android bionic maintainer pointed me
at news coverage of it
http://lists.landley.net/pipermail/toybox-landley.net/2019-June/010536.html

So there would appear to at least be interest in the concept.

(The conclusion I came to looking at it last month is is it can't be done
without kernel support, but if such support _does_ arrive I want to add it to
toybox.)

Rob

2019-06-10 21:10:20

by Rob Landley

[permalink] [raw]
Subject: Re: [PATCH 1/7] signal.h: Define SIGINFO on all architectures

On 6/5/19 3:19 AM, Arseny Maslennikov wrote:
> This complementary patch defines SIGINFO as a synonym for SIGPWR
> on every architecture supported by the kernel.
> The particular signal number chosen does not really matter and is only
> required for the related tty functionality to work properly,
> so if it does not suite expectations, any suggestions are warmly
> welcome.

This was the problem I saw last month: 32 bits worth of signal numbers already
defined, gotta alias something.

> SIGPWR looks like a nice candidate for this role, because it is
> defined on every supported arch; it is currently only used to inform
> PID 1 of power failures, and daemons that care about low-level
> events do not tend to have a controlling terminal.

/dev/console isn't a controlling tty so ctrl-T wouldn't send SIGPWR to PID 1 anyway.

> However, on sparcs SIGPWR is a synonym for SIGLOST, a signal unique
> to that architecture, with a narrow set of intended uses that do not
> combine well with interactively requesting status.
> SIGLOST is not used by any kernel code at the moment.
> I'm not sure there is a more reasonable alternative right now.

The fact it's already _been_ aliased once says it's a good candidate for it. The
easy solution is don't support SIGINFO on sparc until the sparc guys figure out
what to do there and add sparc support in a follow-up patch.

Rob

2019-06-10 21:17:25

by Rob Landley

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

On 6/9/19 3:56 PM, Arseny Maslennikov wrote:
> 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.

Once upon a time suspending pipelines with ctrl-z broke stuff all the time due
to zero length reads being interpreted as EOF. These days I don't see that so
much anymore, I think SA_RESTART is the default now?

Rob

2019-06-12 01:00:32

by Eric W. Biederman

[permalink] [raw]
Subject: Re: [PATCH 1/7] signal.h: Define SIGINFO on all architectures

Arseny Maslennikov <[email protected]> writes:

> This complementary patch defines SIGINFO as a synonym for SIGPWR
> on every architecture supported by the kernel.
> The particular signal number chosen does not really matter and is only
> required for the related tty functionality to work properly,
> so if it does not suite expectations, any suggestions are warmly
> welcome.
>
> SIGPWR looks like a nice candidate for this role, because it is
> defined on every supported arch; it is currently only used to inform
> PID 1 of power failures, and daemons that care about low-level
> events do not tend to have a controlling terminal.
>
> However, on sparcs SIGPWR is a synonym for SIGLOST, a signal unique
> to that architecture, with a narrow set of intended uses that do not
> combine well with interactively requesting status.
> SIGLOST is not used by any kernel code at the moment.
> I'm not sure there is a more reasonable alternative right now.

Is the name SIGINFO already well established.

It just is a little bit confusing with struct siginfo.

At least on x86 it looks like we have signals 32 and 33 that are
reserved and not used for anything. Is there a reason you have
not picked one of those?

Also should this be a realtime signal with signal information
or a non-realtime signal?

I don't expect there is much to encode except that the user is asking
for information. I half wonder if it could be done as a different
si_code to SIGWINCH. But of course that doesn't work because it is
not a real time signal so does not queue more than one siginfo. (Sigh).

I just would like to see that we have a clear concept of how this new
signal plays into all of the signal handling bits.

Added linux-api because this is fundamentally extending the linux-api,
and we probably want man-page updates etc.

Eric

>
> Signed-off-by: Arseny Maslennikov <[email protected]>
> ---
> arch/arm/include/uapi/asm/signal.h | 1 +
> arch/h8300/include/uapi/asm/signal.h | 1 +
> arch/ia64/include/uapi/asm/signal.h | 1 +
> arch/m68k/include/uapi/asm/signal.h | 1 +
> arch/mips/include/uapi/asm/signal.h | 1 +
> arch/parisc/include/uapi/asm/signal.h | 1 +
> arch/powerpc/include/uapi/asm/signal.h | 1 +
> arch/s390/include/uapi/asm/signal.h | 1 +
> arch/sparc/include/uapi/asm/signal.h | 2 ++
> arch/x86/include/uapi/asm/signal.h | 1 +
> arch/xtensa/include/uapi/asm/signal.h | 1 +
> include/uapi/asm-generic/signal.h | 1 +
> 12 files changed, 13 insertions(+)
>
> diff --git a/arch/arm/include/uapi/asm/signal.h b/arch/arm/include/uapi/asm/signal.h
> index 9b4185ba4f8a..b80b53a17267 100644
> --- a/arch/arm/include/uapi/asm/signal.h
> +++ b/arch/arm/include/uapi/asm/signal.h
> @@ -50,6 +50,7 @@ typedef unsigned long sigset_t;
> #define SIGLOST 29
> */
> #define SIGPWR 30
> +#define SIGINFO SIGPWR
> #define SIGSYS 31
> #define SIGUNUSED 31
>
> diff --git a/arch/h8300/include/uapi/asm/signal.h b/arch/h8300/include/uapi/asm/signal.h
> index e15521037348..7a2b783af22b 100644
> --- a/arch/h8300/include/uapi/asm/signal.h
> +++ b/arch/h8300/include/uapi/asm/signal.h
> @@ -50,6 +50,7 @@ typedef unsigned long sigset_t;
> #define SIGLOST 29
> */
> #define SIGPWR 30
> +#define SIGINFO SIGPWR
> #define SIGSYS 31
> #define SIGUNUSED 31
>
> diff --git a/arch/ia64/include/uapi/asm/signal.h b/arch/ia64/include/uapi/asm/signal.h
> index aa98ff1b9e22..b4c98cb17165 100644
> --- a/arch/ia64/include/uapi/asm/signal.h
> +++ b/arch/ia64/include/uapi/asm/signal.h
> @@ -45,6 +45,7 @@
> #define SIGLOST 29
> */
> #define SIGPWR 30
> +#define SIGINFO SIGPWR
> #define SIGSYS 31
> /* signal 31 is no longer "unused", but the SIGUNUSED macro remains for backwards compatibility */
> #define SIGUNUSED 31
> diff --git a/arch/m68k/include/uapi/asm/signal.h b/arch/m68k/include/uapi/asm/signal.h
> index 915cc755a184..a0b4e4108cb8 100644
> --- a/arch/m68k/include/uapi/asm/signal.h
> +++ b/arch/m68k/include/uapi/asm/signal.h
> @@ -50,6 +50,7 @@ typedef unsigned long sigset_t;
> #define SIGLOST 29
> */
> #define SIGPWR 30
> +#define SIGINFO SIGPWR
> #define SIGSYS 31
> #define SIGUNUSED 31
>
> diff --git a/arch/mips/include/uapi/asm/signal.h b/arch/mips/include/uapi/asm/signal.h
> index 53104b10aae2..975a6f0d3b0b 100644
> --- a/arch/mips/include/uapi/asm/signal.h
> +++ b/arch/mips/include/uapi/asm/signal.h
> @@ -43,6 +43,7 @@ typedef unsigned long old_sigset_t; /* at least 32 bits */
> #define SIGCHLD 18 /* Child status has changed (POSIX). */
> #define SIGCLD SIGCHLD /* Same as SIGCHLD (System V). */
> #define SIGPWR 19 /* Power failure restart (System V). */
> +#define SIGINFO SIGPWR /* Keyboard status request (4.2 BSD). */
> #define SIGWINCH 20 /* Window size change (4.3 BSD, Sun). */
> #define SIGURG 21 /* Urgent condition on socket (4.2 BSD). */
> #define SIGIO 22 /* I/O now possible (4.2 BSD). */
> diff --git a/arch/parisc/include/uapi/asm/signal.h b/arch/parisc/include/uapi/asm/signal.h
> index d38563a394f2..fe2e00d590ac 100644
> --- a/arch/parisc/include/uapi/asm/signal.h
> +++ b/arch/parisc/include/uapi/asm/signal.h
> @@ -22,6 +22,7 @@
> #define SIGUSR2 17
> #define SIGCHLD 18
> #define SIGPWR 19
> +#define SIGINFO SIGPWR
> #define SIGVTALRM 20
> #define SIGPROF 21
> #define SIGIO 22
> diff --git a/arch/powerpc/include/uapi/asm/signal.h b/arch/powerpc/include/uapi/asm/signal.h
> index 85b0a7aa43e7..e7f3885905b4 100644
> --- a/arch/powerpc/include/uapi/asm/signal.h
> +++ b/arch/powerpc/include/uapi/asm/signal.h
> @@ -53,6 +53,7 @@ typedef struct {
> #define SIGLOST 29
> */
> #define SIGPWR 30
> +#define SIGINFO SIGPWR
> #define SIGSYS 31
> #define SIGUNUSED 31
>
> diff --git a/arch/s390/include/uapi/asm/signal.h b/arch/s390/include/uapi/asm/signal.h
> index 9a14a611ed82..12ee62987971 100644
> --- a/arch/s390/include/uapi/asm/signal.h
> +++ b/arch/s390/include/uapi/asm/signal.h
> @@ -58,6 +58,7 @@ typedef unsigned long sigset_t;
> #define SIGLOST 29
> */
> #define SIGPWR 30
> +#define SIGINFO SIGPWR
> #define SIGSYS 31
> #define SIGUNUSED 31
>
> diff --git a/arch/sparc/include/uapi/asm/signal.h b/arch/sparc/include/uapi/asm/signal.h
> index ff9505923b9a..b655163198bb 100644
> --- a/arch/sparc/include/uapi/asm/signal.h
> +++ b/arch/sparc/include/uapi/asm/signal.h
> @@ -71,6 +71,8 @@
> #define SIGWINCH 28
> #define SIGLOST 29
> #define SIGPWR SIGLOST
> +/* XXX: is it OK for SIGINFO to collide with LOST? */
> +#define SIGINFO SIGPWR
> #define SIGUSR1 30
> #define SIGUSR2 31
>
> diff --git a/arch/x86/include/uapi/asm/signal.h b/arch/x86/include/uapi/asm/signal.h
> index e5745d593dc7..1539bb28826c 100644
> --- a/arch/x86/include/uapi/asm/signal.h
> +++ b/arch/x86/include/uapi/asm/signal.h
> @@ -55,6 +55,7 @@ typedef unsigned long sigset_t;
> #define SIGLOST 29
> */
> #define SIGPWR 30
> +#define SIGINFO SIGPWR
> #define SIGSYS 31
> #define SIGUNUSED 31
>
> diff --git a/arch/xtensa/include/uapi/asm/signal.h b/arch/xtensa/include/uapi/asm/signal.h
> index 005dec5bfde4..d644234305de 100644
> --- a/arch/xtensa/include/uapi/asm/signal.h
> +++ b/arch/xtensa/include/uapi/asm/signal.h
> @@ -65,6 +65,7 @@ typedef struct {
> #define SIGPOLL SIGIO
> /* #define SIGLOST 29 */
> #define SIGPWR 30
> +#define SIGINFO SIGPWR
> #define SIGSYS 31
> #define SIGUNUSED 31
>
> diff --git a/include/uapi/asm-generic/signal.h b/include/uapi/asm-generic/signal.h
> index 5c716a952cbe..9f9a1db0d43c 100644
> --- a/include/uapi/asm-generic/signal.h
> +++ b/include/uapi/asm-generic/signal.h
> @@ -43,6 +43,7 @@
> #define SIGLOST 29
> */
> #define SIGPWR 30
> +#define SIGINFO SIGPWR
> #define SIGSYS 31
> #define SIGUNUSED 31

2019-06-12 05:24:10

by Arseny Maslennikov

[permalink] [raw]
Subject: Re: [PATCH 1/7] signal.h: Define SIGINFO on all architectures

On Tue, Jun 11, 2019 at 03:36:00PM -0500, Eric W. Biederman wrote:
> Arseny Maslennikov <[email protected]> writes:
>
> > This complementary patch defines SIGINFO as a synonym for SIGPWR
> > on every architecture supported by the kernel.
> > The particular signal number chosen does not really matter and is only
> > required for the related tty functionality to work properly,
> > so if it does not suite expectations, any suggestions are warmly
> > welcome.
> >
> > SIGPWR looks like a nice candidate for this role, because it is
> > defined on every supported arch; it is currently only used to inform
> > PID 1 of power failures, and daemons that care about low-level
> > events do not tend to have a controlling terminal.
> >
> > However, on sparcs SIGPWR is a synonym for SIGLOST, a signal unique
> > to that architecture, with a narrow set of intended uses that do not
> > combine well with interactively requesting status.
> > SIGLOST is not used by any kernel code at the moment.
> > I'm not sure there is a more reasonable alternative right now.
>
> Is the name SIGINFO already well established.
>
> It just is a little bit confusing with struct siginfo.
>

I thought about this, but the alternatives are clunkier.
SIGKBINFO? Implies there actually is a keyboard, most ttys are
virtual/software nowadays. Misplaced emphasis.
SIGSTATUS? Too generic.
SIGTINFO? This could work, like conveys the nature and all, but many
applications already do #ifdef SIGINFO; if we reuse the name they will
suddenly just work, and this helps adoption.
SIGTINFO does decipher to "terminal info", this sounds too ambiguous.

Fortunately, from UNIX tradition signal names are defined in caps, and
given there is much more related written discussion than spoken, this
stands out enough to my taste. I'd say, it stands out a lot.

> At least on x86 it looks like we have signals 32 and 33 that are
> reserved and not used for anything. Is there a reason you have
> not picked one of those?

Quoting signal(7) from man-pages:
The Linux kernel supports a range of 33 different real-time
signals, numbered 32 to 64. However, the glibc POSIX
threads implementation internally uses two (for NPTL) or
three (for LinuxThreads) real-time signals (see
pthreads(7)), and adjusts the value of SIGRTMIN suitably
(to 34 or 35).

This excerpt gives the cue that signals 32 and 33 are not really unused,
and I did not want to cause further adjustments to SIGRTMIN/SIGRTMAX,
since this means we have to recompile the world with the new, changed
SIGRTMIN/MAX...

If we'd change RTMIN, this makes all the rt signal numbers shift to the
right and can cause havoc if we do not recompile the world.

We could probably go with decrementing RTMAX and reusing the value
(effectively reserving a signal number from the end), but aliasing PWR
seems much easier and less harmful, and easier for apps to adopt.
If we find a strong reason not to reuse PWR, this may be considered as a
plan B, but the idea to allocate even more precious signals seems too
wasteful to me for now.

>
> Also should this be a realtime signal with signal information
> or a non-realtime signal?

I see no requirement for this to be a realtime signal.

Non-realtime signals like PWR or INT also have at least some signal
information which can be accessed with handlers installed with
sigaction(2). [1] has a small example.
The most obvious piece of info is that signals sent by n_tty
(si_code==SI_KERNEL) are easy to distinguish from signals sent by
processes (si_code==SI_USER)

>
> I don't expect there is much to encode except that the user is asking
> for information. I half wonder if it could be done as a different
> si_code to SIGWINCH. But of course that doesn't work because it is
> not a real time signal so does not queue more than one siginfo. (Sigh).
>

Signals are just a huge mess (not that this is news...) :)

> I just would like to see that we have a clear concept of how this new
> signal plays into all of the signal handling bits.
>
> Added linux-api because this is fundamentally extending the linux-api,
> and we probably want man-page updates etc.
>
> Eric
>

[1]https://github.com/porrided/tty-kb-status-userspace/blob/d32028056c85b279cf8d5f43478b5419d090637c/siginfo-test/siginfo.c


Attachments:
(No filename) (4.32 kB)
signature.asc (849.00 B)
Download all attachments

2019-06-12 09:43:32

by Pavel Machek

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

Hi!

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

Ok, so this should be safe as long as noone listens for SIGPWR. So
... I guess we are ok :-).
Pavel


--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


Attachments:
(No filename) (1.39 kB)
signature.asc (188.00 B)
Digital signature
Download all attachments