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(-)
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.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 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
On 10/13/2014 03:41 PM, One Thousand Gnomes wrote:
> 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.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 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.
> 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,
On Mon, Oct 13, 2014 at 10:24:53PM +0200, Helge Deller wrote:
> On 10/13/2014 03:41 PM, One Thousand Gnomes wrote:
> >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.