[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20141013144143.475ca9f9@alan.etchedpixels.co.uk>
Date: Mon, 13 Oct 2014 14:41:43 +0100
From: One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>
To: Helge Deller <deller@....de>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
linux-kernel@...r.kernel.org, linux-parisc@...r.kernel.org,
James Bottomley <James.Bottomley@...senPartnership.com>,
John David Anglin <dave.anglin@...l.net>,
"Carlos O'Donell" <carlos@...temhalted.org>
Subject: Re: [GIT PULL] parisc architecture patch for v3.18
On Sun, 12 Oct 2014 12:08:37 +0200
Helge Deller <deller@....de> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists