All of lore.kernel.org
 help / color / mirror / Atom feed
From: catalin.marinas@arm.com (Catalin Marinas)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] arm64: uapi: expose our struct ucontext to the uapi headers
Date: Fri, 16 Jan 2015 14:47:38 +0000	[thread overview]
Message-ID: <20150116144737.GB10230@localhost> (raw)
In-Reply-To: <1421416334-12588-1-git-send-email-will.deacon@arm.com>

On Fri, Jan 16, 2015 at 01:52:14PM +0000, Will Deacon wrote:
> arm64 defines its own ucontext structure which is incompatible with the
> struct defined (and exposed to userspace by) the asm-generic headers.
> 
> glibc carries its own struct definition that is compatible with the
> arm64 definition, but we should expose our format in the uapi headers in
> case other libraries want to make use of the ucontext pushed as part of
> an arm64 sigframe.
> 
> This patch moves the arm64 asm/ucontext.h to the uapi headers, along
> with the necessary #include of linux/types.h.
> 
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Marcus Shawcroft <marcus.shawcroft@arm.com>
> Signed-off-by: Will Deacon <will.deacon@arm.com>
> ---
> 
> I think we also need something similar for arch/arm/ unless we decide
> that exposing the incorrect asm-generic header is harmless.

I'm trying to understand how we got here on arm32 (arm64 pretty much
inherited the behaviour). Before the uapi headers split, we had
arch/arm/include/asm/ucontext.h which has an #ifdef __KERNEL__ and
struct ucontext defined outside this block but we don't seem to have
ever exported this header to user. Luckily, glibc uses its own
definition which matches the kernel one.

At some point the asm-generic gained a ucontext.h which is fine but it
was not ending up in user space as we had an arch ucontext.h. However,
with the uapi headers change and maybe some additional commits, we end
up copying the uapi/asm-generic/ucontext.h to usr/include/asm/ in the
exported headers which differs from the arch ucontext.h as the latter
was never split in uapi/non-uapi parts (it wasn't in the
arch/arm/include/Kbuild).

>  arch/arm64/include/uapi/asm/Kbuild           | 1 +
>  arch/arm64/include/{ => uapi}/asm/ucontext.h | 8 +++++---
>  2 files changed, 6 insertions(+), 3 deletions(-)
>  rename arch/arm64/include/{ => uapi}/asm/ucontext.h (88%)

For this patch:

Acked-by: Catalin Marinas <catalin.marinas@arm.com>

For arm32 I think we need to split ucontext.h into uapi and non-uapi
part according to the #ifdef __KERNEL__.

Catalin

  reply	other threads:[~2015-01-16 14:47 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-16 13:52 [PATCH] arm64: uapi: expose our struct ucontext to the uapi headers Will Deacon
2015-01-16 14:47 ` Catalin Marinas [this message]
2015-01-16 15:26   ` Arnd Bergmann
2015-01-16 15:35     ` Catalin Marinas
2015-01-16 15:37       ` Will Deacon
2015-01-16 15:38         ` Catalin Marinas

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=20150116144737.GB10230@localhost \
    --to=catalin.marinas@arm.com \
    --cc=linux-arm-kernel@lists.infradead.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.