linux-mips
[Top] [All Lists]

Re: MIPS MSA sigcontext changes in 3.15

To: <linux-mips@linux-mips.org>, <libc-alpha@sourceware.org>, <linux-api@vger.kernel.org>
Subject: Re: MIPS MSA sigcontext changes in 3.15
From: "Joseph S. Myers" <joseph@codesourcery.com>
Date: Tue, 17 Jun 2014 15:44:36 +0000
In-reply-to: <Pine.LNX.4.64.1406171447030.23412@digraph.polyomino.org.uk>
List-archive: <http://www.linux-mips.org/archives/linux-mips/>
List-help: <mailto:ecartis@linux-mips.org?Subject=help>
List-id: linux-mips <linux-mips.eddie.linux-mips.org>
List-owner: <mailto:ralf@linux-mips.org>
List-post: <mailto:linux-mips@linux-mips.org>
List-software: Ecartis version 1.0.0
List-subscribe: <mailto:ecartis@linux-mips.org?subject=subscribe%20linux-mips>
List-unsubscribe: <mailto:ecartis@linux-mips.org?subject=unsubscribe%20linux-mips>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <Pine.LNX.4.64.1406171447030.23412@digraph.polyomino.org.uk>
Sender: linux-mips-bounce@linux-mips.org
On Tue, 17 Jun 2014, Joseph S. Myers wrote:

> signal mask at a particular offset in the ucontext.  As far as I can see, 
> extending sigcontext requires a new sigaction flag that could be used to 
> opt in, for a particular signal handler, to receiving the new-layout 
> ucontext (so new symbol versions of sigaction in glibc could then pass 
> that flag to the kernel, but existing binaries would continue to get 
> old-layout ucontext from the kernel), or else putting the new data at the 

And a new flag would itself be problematic - signal handlers would need 
wrapping with userspace code to convert structure layout when new-version 
sigaction is used on an older kernel.  That suggests putting the new data 
at the end of ucontext is to be preferred (but in any case it would be 
best to revert the incompatible changes until something compatible with 
existing userspace can be produced).

-- 
Joseph S. Myers
joseph@codesourcery.com

<Prev in Thread] Current Thread [Next in Thread>