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 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-timesignals(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 signature.asc Description: PGP signature
Re: [PATCH 1/7] signal.h: Define SIGINFO on all architectures
Arseny Maslennikov 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 > --- > 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 reques
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
