From mboxrd@z Thu Jan 1 00:00:00 1970 From: catalin.marinas@arm.com (Catalin Marinas) Date: Thu, 18 Oct 2018 12:14:36 +0100 Subject: [PATCH v9 00/24] ILP32 for ARM64 In-Reply-To: References: <20180516081910.10067-1-ynorov@caviumnetworks.com> Message-ID: <20181018111435.GA237391@arrakis.emea.arm.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Sun, Oct 14, 2018 at 09:49:01PM +0200, Arnd Bergmann wrote: > On Sat, Oct 13, 2018 at 9:36 PM Andy Lutomirski wrote: > > > > On Wed, May 16, 2018 at 1:19 AM Yury Norov wrote: > > > > > > This series enables AARCH64 with ILP32 mode. > > > > > > As supporting work, it introduces ARCH_32BIT_OFF_T configuration > > > option that is enabled for existing 32-bit architectures but disabled > > > for new arches (so 64-bit off_t userspace type is used by new userspace). > > > Also it deprecates getrlimit and setrlimit syscalls prior to prlimit64. > > > > Second, ILP32 user code is highly unlikely > > to end up with the same struct layout as ILP64 code. The latter seems > > like it should be solved entirely in userspace by adding a way to > > annotate a structure as being a kernel ABI structure and getting the > > toolchain to lay it out as if it were ILP64 even though the target is > > ILP32. > > The syscall ABI could be almost completely abstracted in glibc, the > main issue is ioctl and a couple of related interfaces that pass data > structures (read() on /dev/input/*, mmap on /dev/snd/* > or raw sockets, fcntl). There is another case on struct siginfo which has some pointers and it wouldn't look like an LP64 structure at all (and glibc doesn't normally intercept the sighandler call to rewrite the structure). We could add padding around void * members as the kernel zeros them, I don't recall the kernel reading these pointers from user. Anyway, using something that resembles compat_siginfo looked the simplest for ILP32. -- Catalin