From: ynorov@caviumnetworks.com (Yury Norov)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v6 12/20] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it
Date: Wed, 23 Dec 2015 21:31:45 +0300 [thread overview]
Message-ID: <20151223183145.GA27193@yury-N73SV> (raw)
In-Reply-To: <201512212331.58152.arnd@arndb.de>
On Mon, Dec 21, 2015 at 11:31:57PM +0100, Arnd Bergmann wrote:
> On Tuesday 15 December 2015, Yury Norov wrote:
> > +
> > +#define compat_sys_open_by_handle_at sys_open_by_handle_at
> > +#define compat_sys_openat sys_openat
> > +
>
> One more thing I just remembered: I think we want this behavior for all new
> 32-bit architectures, it was a bug to call compat_sys_openat for the generic
> syscall table, as we don't support 32-bit off_t.
>
> Could you split this out into a separate patch that does these changes:
>
> - change the default asm-generic/unistd.h to use sys_openat/sys_open_by_handle_at
> - change tile to override those two to keep the current (suboptimal) behavior
> - change the force_o_largefile() definition so it defaults to true for all future
> architectures. The easiest way is probably to add a Kconfig symbol for this
> that gets selected by all 32-bit architectures, so we can use
>
> #define force_o_largefile() ((BITS_PER_LONG != 32) || !IS_ENABLED(CONFIG_ARCH_32BIT_OFF_T))
>
Hi Arnd,
First two items are OK. The last one... Do you need it to remove
compat_sys_openat and compat_sys_open_by_handle_at?
The patch that introduces CONFIG_ARCH_32BIT_OFF_T will affect all
architectures, and so I need to get ack from each maintainer.
I will also have to ask them to test that change, because I have no
access to all the hardware. (Even with QEMU, I cannot test them all.)
I think the only man who is able to success with it is Linus :)...
Some arches has more than one compat mode. For example ARM64: aarch32
requires this config enabled, but ilp32 needs it disabled. Now we can
enable both features, but this will make them mutual exclusive. We can
instead (un)define __ARCH_WANT_32BIT_OFF_T for each ABI of each platform,
but it's even more work. And we'd think twice how to do it because
it's not mechanical work. For example, on aarch64 it will look like:
#define __ARCH_WANT_32BIT_OFF_T is_a32_compat_task()
I have no idea how it will look on x86 or ppc.
In your previous email (Nov 18) you write that tile is the only user
of asm-generic/unistd.h that needs compat behaviour. If so, why not
just to turn it around, as you initially suggested, and fix tile. And
do nothing with force_o_largefile()?
By the way, is there a comprehensive list of linux platforms/abis, or
at least ones that use asm-generic/unistd.h?
BR,
Yury.
> Arnd
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2015-12-23 18:31 UTC|newest]
Thread overview: 78+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-15 21:42 [RFC3 PATCH v6 00/20] ILP32 for ARM64 Yury Norov
2015-12-15 21:42 ` [PATCH v6 01/20] arm64: ilp32: add documentation on the ILP32 ABI " Yury Norov
2015-12-15 21:42 ` [PATCH v6 02/20] arm64: ensure the kernel is compiled for LP64 Yury Norov
2015-12-15 21:42 ` [PATCH v6 03/20] arm64: rename COMPAT to AARCH32_EL0 in Kconfig Yury Norov
2015-12-17 11:23 ` Catalin Marinas
2015-12-15 21:42 ` [PATCH v6 04/20] arm64: change some CONFIG_COMPAT over to use CONFIG_AARCH32_EL0 instead Yury Norov
2015-12-23 14:15 ` Yury Norov
2015-12-28 8:43 ` > diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile Bamvor Jian Zhang
2015-12-28 9:01 ` [PATCH v6 04/20] arm64: change some CONFIG_COMPAT over to use CONFIG_AARCH32_EL0 instead Zhangjian (Bamvor)
2015-12-29 12:27 ` Yury Norov
2015-12-29 14:59 ` [PATCH] arm64: compat: fix wrong dependency Bamvor Jian Zhang
2015-12-29 13:12 ` [PATCH v6 04/20] arm64: change some CONFIG_COMPAT over to use CONFIG_AARCH32_EL0 instead Yury Norov
2015-12-15 21:42 ` [PATCH v6 05/20] arm64:uapi: set __BITS_PER_LONG correctly for ILP32 and LP64 Yury Norov
2015-12-15 21:42 ` [PATCH v6 06/20] thread: move thread bits accessors to separated file Yury Norov
2015-12-15 21:42 ` [PATCH v6 07/20] arm64: introduce is_a32_task and is_a32_thread (for AArch32 compat) Yury Norov
2015-12-17 11:38 ` Catalin Marinas
2015-12-15 21:42 ` [PATCH v6 08/20] arm64: ilp32: add is_ilp32_compat_{task, thread} and TIF_32BIT_AARCH64 Yury Norov
2015-12-17 11:41 ` Catalin Marinas
2015-12-18 14:11 ` Yury Norov
2015-12-18 14:44 ` Yury Norov
2015-12-21 17:42 ` Catalin Marinas
2015-12-15 21:42 ` [PATCH v6 09/20] arm64:ilp32: share HWCAP between LP64 and ILP32 Yury Norov
2015-12-16 15:54 ` Arnd Bergmann
2015-12-16 16:58 ` Catalin Marinas
2015-12-16 17:19 ` Catalin Marinas
2015-12-16 19:17 ` Arnd Bergmann
2015-12-17 10:54 ` Catalin Marinas
2015-12-17 13:56 ` Arnd Bergmann
2015-12-15 21:42 ` [PATCH v6 10/20] arm64:ilp32 use the native LP64 'start_thread' for ILP32 threads Yury Norov
2015-12-16 15:50 ` Arnd Bergmann
2015-12-18 13:57 ` Yury Norov
2015-12-15 21:42 ` [PATCH v6 11/20] arm64:ilp32: support core dump generation for ILP32 Yury Norov
2015-12-17 14:05 ` Catalin Marinas
2015-12-15 21:42 ` [PATCH v6 12/20] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it Yury Norov
2015-12-16 16:07 ` Arnd Bergmann
2015-12-17 18:27 ` Catalin Marinas
2015-12-17 20:10 ` Arnd Bergmann
2015-12-17 20:14 ` Andrew Pinski
2015-12-17 20:50 ` Arnd Bergmann
2016-01-05 15:26 ` Yury Norov
2016-01-05 21:12 ` Arnd Bergmann
2016-01-06 17:10 ` Catalin Marinas
2016-01-07 14:13 ` Arnd Bergmann
2016-01-07 15:42 ` Yury Norov
2016-01-07 17:23 ` Catalin Marinas
2015-12-18 11:42 ` Catalin Marinas
2015-12-18 12:47 ` Arnd Bergmann
2015-12-21 18:31 ` Catalin Marinas
2015-12-21 22:19 ` Arnd Bergmann
2015-12-21 18:39 ` Dr. Philipp Tomsich
2015-12-21 22:13 ` Arnd Bergmann
2015-12-21 22:31 ` Arnd Bergmann
2015-12-23 18:31 ` Yury Norov [this message]
2015-12-23 21:48 ` Arnd Bergmann
2015-12-15 21:42 ` [PATCH v6 13/20] arm64: ilp32: share aarch32 syscall wrappers to ilp32 Yury Norov
2015-12-17 14:38 ` Andreas Schwab
2015-12-18 13:49 ` Yury Norov
2015-12-22 12:25 ` Catalin Marinas
2015-12-22 21:44 ` Arnd Bergmann
2015-12-23 13:37 ` Catalin Marinas
2015-12-23 20:41 ` Arnd Bergmann
2015-12-30 17:29 ` Yury Norov
2015-12-30 22:36 ` Arnd Bergmann
2015-12-23 4:21 ` Yury Norov
2015-12-15 21:42 ` [PATCH v6 14/20] arm64: signal: wrap struct ucontext, fp and lr with struct sigframe Yury Norov
2015-12-15 21:42 ` [PATCH v6 15/20] arm64: signal: move ilp32 and lp64 common code to separated file Yury Norov
2015-12-16 16:08 ` Arnd Bergmann
2015-12-18 13:48 ` Yury Norov
2015-12-18 14:09 ` Arnd Bergmann
2015-12-22 17:11 ` Catalin Marinas
2015-12-15 21:42 ` [PATCH v6 16/20] arm64: signal32: move ilp32 and aarch32 " Yury Norov
2015-12-22 14:29 ` Catalin Marinas
2015-12-15 21:42 ` [PATCH v6 17/20] arm64: ilp32: introduce ilp32-specific handlers for sigframe Yury Norov
2015-12-22 17:08 ` Catalin Marinas
2015-12-15 21:42 ` [PATCH v6 18/20] arm64:ilp32: add vdso-ilp32 and use for signal return Yury Norov
2015-12-15 21:42 ` [PATCH v6 19/20] arm64:ilp32: change COMPAT_ELF_PLATFORM to report a a subplatform for ILP32 Yury Norov
2015-12-15 21:42 ` [PATCH v6 20/20] arm64:ilp32: add ARM64_ILP32 to Kconfig Yury Norov
2015-12-16 16:24 ` [RFC3 PATCH v6 00/20] ILP32 for ARM64 Arnd Bergmann
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=20151223183145.GA27193@yury-N73SV \
--to=ynorov@caviumnetworks.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).