[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5805597.NtPXVqS0W3@wuerfel>
Date: Tue, 17 Nov 2015 23:14:25 +0100
From: Arnd Bergmann <arnd@...db.de>
To: linux-arm-kernel@...ts.infradead.org
Cc: Yury Norov <ynorov@...iumnetworks.com>, catalin.marinas@....com,
linux-kernel@...r.kernel.org, pinskia@...il.com,
Prasun.Kapoor@...iumnetworks.com, schwab@...e.de,
Nathan_Lynch@...tor.com, agraf@...e.de, klimov.linux@...il.com,
broonie@...nel.org, jan.dakinevich@...il.com,
ddaney.cavm@...il.com, bamvor.zhangjian@...wei.com,
philipp.tomsich@...obroma-systems.com, andrey.konovalov@...aro.org,
joseph@...esourcery.com, christoph.muellner@...obroma-systems.com
Subject: Re: [PATCH v6 06/19] arm64:ilp32: share signal structures between ILP32 and LP64 ABIs
On Wednesday 18 November 2015 00:16:46 Yury Norov wrote:
>
> +/* For ILP32, sigset should be the same size fields as LP64 so use
> + unsigned long long. */
> +#ifdef __ILP32__
> +#define __SIGSET_INNER_TYPE __extension__ unsigned long long
> +#define _NSIG_BPW 64
> +
> +# ifdef __AARCH64EB__
> +# define __SIGNAL_INNER(type, field) \
> + __extension__ struct { \
> + int __pad_##field; \
> + type field; \
> + } __attribute__((aligned(8)))
> +# else
> +# define __SIGNAL_INNER(type, field) \
> + __extension__ struct { \
> + type field; \
> + int __pad_##field; \
> + } __attribute__((aligned(8)))
> +# endif
> +
> +# define __SIGACTION_HANDLER(field) \
> + __SIGNAL_INNER(__sighandler_t, field)
> +
> +#define __SIGACTION_FLAGS(field) \
> + __extension__ unsigned long long field
> +
> +#define __SIGACTION_RESTORER(field) \
> + __SIGNAL_INNER(__sigrestore_t, field)
> +
> +#endif
Ah, I missed that in the comments for patch 14. I would think that
it makes sense to share siginfo_t with the 64-bit version, when the
normal compat_siginfo_t doesn't work, but I see no point in
changing compat_sigset_t: There is nothing architecture specific
in that, so you can just use the arm32 version of that, which simplifies
both the kernel and libc sides.
Arnd
--
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