parisc architecture patch for v3.18
Hi Linus,
please pull one patch for the parisc architecture for kernel 3.18 from
git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux.git parisc-3.18-1
This patch intentionally breaks the ABI on PARISC Linux!
It assigns new numbers to SIGSTKFLT, SIGXCPU, SIGXFSZ and SIGSYS so that those are below 32 and thus leaves us with 32 RT signals like other Linux architectures (SIGRTMIN now becomes 32 instead of 37).
Even if it breaks the ABI, it doesn't seem to have any visible impact on existing userspace applications. I was able to mix new kernel and/or glibc without impacting normal bootup. So, even if it breaks the ABI, the benefits (e.g. being able to use systemd on PARISC Linux) outperforms the minimal (if any) impact it gives.
The patch has been discussed on the parisc kernel mailing list and the coresponding glibc patch will be committed by the parisc glibc maintainer after this patch went into 3.18.
Some more background information about this patch is in the commit message.
Thanks,
Helge
----------------------------------------------------------------
Helge Deller (1):
parisc: Reduce SIGRTMIN from 37 to 32 to behave like other Linux architectures
arch/parisc/include/uapi/asm/signal.h | 16 ++++++---------- 1 file changed, 6 insertions(+), 10 deletions(-)
Quoted 5 lines · On Sun, 12 Oct 2014 12:08:37 +0200 Helge Deller <[email protected]> wrote:
Hi Linus,
please pull one patch for the parisc architecture for kernel 3.18 from
git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux.gitparisc-3.18-1
Quoted 8 lines
This patch intentionally breaks the ABI on PARISC Linux!
It assigns new numbers to SIGSTKFLT, SIGXCPU, SIGXFSZ and SIGSYS so that those are below 32 and thus leaves us with 32 RT signals like other Linux architectures (SIGRTMIN now becomes 32 instead of 37).
Even if it breaks the ABI, it doesn't seem to have any visible impact on existing userspace applications.
I somehow doubt your kill command magically corrects its signal numbering table. Likewise what does gdb do given a core dump that died from one of those signals, and what does your shell report if you kill one that way. It seems to me your minimal set of binaries to swap to get it right is non-zero but not problematic (libc, kill, shells, top, gdb) ?
I can however really only think of one app that actually *used* SIGXCPU, and that was to respawn itself to avoid annoying sysadmin set CPU limits anyway.
Alan
Quoted 14 lines · One Thousand Gnomes
Quoted 11 lines · On Sun, 12 Oct 2014 12:08:37 +0200 Helge Deller <[email protected]> wrote:
Hi Linus,
please pull one patch for the parisc architecture for kernel 3.18 from
git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux.gitparisc-3.18-1This patch intentionally breaks the ABI on PARISC Linux!
It assigns new numbers to SIGSTKFLT, SIGXCPU, SIGXFSZ and SIGSYS so that those are below 32 and thus leaves us with 32 RT signals like other Linux architectures (SIGRTMIN now becomes 32 instead of 37).
Quoted 8 lines
Quoted 2 lines
Even if it breaks the ABI, it doesn't seem to have any visible impact on existing userspace applications.
I somehow doubt your kill command magically corrects its signal numbering table. Likewise what does gdb do given a core dump that died from one of those signals, and what does your shell report if you kill one that way. It seems to me your minimal set of binaries to swap to get it right is non-zero but not problematic (libc, kill, shells, top, gdb) ?
My patch of course just marks the start of a transition phase, in which some few applications need to be rebuilt (libc as the most important one). But after all it makes a somewhat smooth transition possible, and as I wrote in the commit message this is the best solution (out of 3) with the least impact which we have.
Quoted 3 lines
I can however really only think of one app that actually *used* SIGXCPU, and that was to respawn itself to avoid annoying sysadmin set CPU limits anyway.
:-)
Helge
Hi,
Quoted 9 lines · Helge Deller
Quoted 5 lines · One Thousand Gnomes
I somehow doubt your kill command magically corrects its signal numbering table. Likewise what does gdb do given a core dump that died from one of those signals, and what does your shell report if you kill one that way. It seems to me your minimal set of binaries to swap to get it right is non-zero but not problematic (libc, kill, shells, top, gdb) ?
My patch of course just marks the start of a transition phase, in which some few applications need to be rebuilt (libc as the most important one).
Busybox handles changed signals correctly after rebuilding against new headers. Based on quick look, GDB has never known about PA-RISC specific numbers, so it has probably always reported some wrong signal name...
A.