All of lore.kernel.org
 help / color / mirror / Atom feed
From: Helge Deller <deller@gmx.de>
To: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	linux-kernel@vger.kernel.org, linux-parisc@vger.kernel.org,
	James Bottomley <James.Bottomley@HansenPartnership.com>,
	John David Anglin <dave.anglin@bell.net>,
	Carlos O'Donell <carlos@systemhalted.org>
Subject: Re: [GIT PULL] parisc architecture patch for v3.18
Date: Mon, 13 Oct 2014 22:24:53 +0200	[thread overview]
Message-ID: <543C3515.9090000@gmx.de> (raw)
In-Reply-To: <20141013144143.475ca9f9@alan.etchedpixels.co.uk>

On 10/13/2014 03:41 PM, One Thousand Gnomes wrote:
> On Sun, 12 Oct 2014 12:08:37 +0200
> Helge Deller <deller@gmx.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) ?

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

  reply	other threads:[~2014-10-13 20:24 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-12 10:08 [GIT PULL] parisc architecture patch for v3.18 Helge Deller
2014-10-13 13:41 ` One Thousand Gnomes
2014-10-13 20:24   ` Helge Deller [this message]
2014-10-13 21:32     ` Aaro Koskinen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=543C3515.9090000@gmx.de \
    --to=deller@gmx.de \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=carlos@systemhalted.org \
    --cc=dave.anglin@bell.net \
    --cc=gnomes@lxorguk.ukuu.org.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-parisc@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.