From: Arnd Bergmann <arnd@arndb.de> To: linux-arm-kernel@lists.infradead.org Cc: "Dr. Philipp Tomsich" <philipp.tomsich@theobroma-systems.com>, Catalin Marinas <catalin.marinas@arm.com>, Andreas Kraschitzer <andreas.kraschitzer@theobroma-systems.com>, linux-kernel@vger.kernel.org, Andrew Pinski <apinski@cavium.com>, Kumar Sankaran <ksankaran@apm.com>, Benedikt Huber <benedikt.huber@theobroma-systems.com>, Christoph Muellner <christoph.muellner@theobroma-systems.com> Subject: Re: [PATCH v4 00/24] ILP32 for ARM64 Date: Wed, 15 Apr 2015 14:42:43 +0200 [thread overview] Message-ID: <12636371.MavevVFsON@wuerfel> (raw) In-Reply-To: <9F7FC15C-EED1-4939-B66A-1BC3119E0D9C@theobroma-systems.com> On Tuesday 14 April 2015 17:29:36 Dr. Philipp Tomsich wrote: > > > On 14 Apr 2015, at 16:47, Catalin Marinas <catalin.marinas@arm.com> wrote: > > > >> I mainly want to avoid accidentally creating new ABIs for syscalls and ioctls: > >> we have many drivers that today use ioctls with data structures derived from > >> '__kernel_ulong_t' in some form, often by including a timespec or time_t in > >> their own data structures. These are almost all broken today, because the > >> data structures are a mix of the aarch32 and aarch64 variants, while the > >> ioctl() system call in ilp32 always uses the aarch32 format by default. > >> > >> An example here would be > >> > >> struct cyclades_idle_stats { > >> __kernel_time_t in_use; /* Time device has been in use (secs) */ > >> __kernel_time_t recv_idle; /* Time since last char received (secs) */ > >> __kernel_time_t xmit_idle; /* Time since last char transmitted (secs) */ > >> unsigned long recv_bytes; /* Bytes received */ > >> unsigned long xmit_bytes; /* Bytes transmitted */ > >> unsigned long overruns; /* Input overruns */ > >> unsigned long frame_errs; /* Input framing errors */ > >> unsigned long parity_errs; /* Input parity errors */ > >> }; > >> > >> for a random ancient driver. Introducing a third set of data structures > >> and syscalls for aarch64-ilp32 means that any driver doing something like > >> this needs to be modified to support existing user space source code. > > > > That's indeed a problem as ILP32 doesn't look like any of the other > > options (the siginfo structure is another case that doesn't fit in any > > of the ABI as long as time_t is 64-bit). > > I believe we’ve already arrived at the conclusion that timespec needs to be > changed from what Andrew and I had submitted. > > Let’s go back to the underlying definition of timespec: > "The range and precision of times representable in clock_t and time_t are > implementation-defined. The timespec structure shall contain at least the > following members, in any order. > > time_t tv_sec; // whole seconds -- >= 0 > long tv_nsec; // nanoseconds -- [0, 999999999]” > > So tv_nsec needs to be 32bit on ILP32, as we would otherwise break the C > language. Any program that assumes that tv_nsec is sizeof(long) would be > correct and it would be unexpected and surprising behaviour [even though it > would be consider a good programming style] if one would need to explicitly > ask for the sizeof(ts.tv_nsec). Having the same problem on x32 doesn’t seem > like a good justification to do the same. I don't think assuming that people who don't write 64-bit safe code write code that follows C11 is realistic ;-) A lot more code is broken by having a 64-bit time_t than would be broken by making tv_nsec 64-bit. > For time_t, I don’t see the need to have a 32bit type yet. > As long as the the type is properly exposed through header files (and user > programs can thus recreate the kernel’s data model), we should be safe. > > Cases like the above data structure from an ioctl are clearly non-portable > and would break today on any architecture that supports ABIs with different > data models (say ILP32 and LP64)… so I would consider any attempt to > support this as trying to remain “bug-compatible”. > > There are plenty of good examples in the uapi that will be nicely portable > between ILP32 and LP64. Let’s take aio_abi.h (I’ve intentionally chosen this, > as the userspace library libaio uses a broken redefinition instead of the > kernel header file) as an example: > > /* > > ... structures that done in modern times by competent developers should all be the same across the three ABIs, no need to worry about that. The only worrying part is drivers that are written in an incompatible form for whatever reason. These have become rarer in the recent years, but we still see new ones getting merged, e.g. the Android binder. > The key to any design decision should be that we > (a) don’t break C11, POSIX or the Single UNIX Specification > (b) remain true to the definitions from the the AArch64 ILP32 ELF ABI > (which defines 64bit values transferable in registers to callees) These are nice goals, but I don't think they primary objectives. Getting things to work is much more important, and the timespec definition among other things may end up not being standards compliant in order to get there. > Can we thus agree on the following for the next revision of the patch-set: > (1) We retain a 64bit time_t, but implement different sizes (between ILP32 and > LP64) for ‘tv_nsec' in 'struct timespec’? I have a plan for addressing that, but it will likely take another year before we can get consensus on the timespec layout for 64-bit time_t. At the moment, it looks like the 64/64 layout has more support than the 64/pad/32 layout you are describing. Let's not rush this for aarch64 when there is a chance that we end up with a different layout on native 32-bit machines. > (2) We use the 64bit system calls whereever possible (i.e. no register splitting). I'm fine with using 64-bit registers for passing loff_t if we use the asm-generic/unistd.h system call numbers. Arnd
WARNING: multiple messages have this Message-ID (diff)
From: arnd@arndb.de (Arnd Bergmann) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH v4 00/24] ILP32 for ARM64 Date: Wed, 15 Apr 2015 14:42:43 +0200 [thread overview] Message-ID: <12636371.MavevVFsON@wuerfel> (raw) In-Reply-To: <9F7FC15C-EED1-4939-B66A-1BC3119E0D9C@theobroma-systems.com> On Tuesday 14 April 2015 17:29:36 Dr. Philipp Tomsich wrote: > > > On 14 Apr 2015, at 16:47, Catalin Marinas <catalin.marinas@arm.com> wrote: > > > >> I mainly want to avoid accidentally creating new ABIs for syscalls and ioctls: > >> we have many drivers that today use ioctls with data structures derived from > >> '__kernel_ulong_t' in some form, often by including a timespec or time_t in > >> their own data structures. These are almost all broken today, because the > >> data structures are a mix of the aarch32 and aarch64 variants, while the > >> ioctl() system call in ilp32 always uses the aarch32 format by default. > >> > >> An example here would be > >> > >> struct cyclades_idle_stats { > >> __kernel_time_t in_use; /* Time device has been in use (secs) */ > >> __kernel_time_t recv_idle; /* Time since last char received (secs) */ > >> __kernel_time_t xmit_idle; /* Time since last char transmitted (secs) */ > >> unsigned long recv_bytes; /* Bytes received */ > >> unsigned long xmit_bytes; /* Bytes transmitted */ > >> unsigned long overruns; /* Input overruns */ > >> unsigned long frame_errs; /* Input framing errors */ > >> unsigned long parity_errs; /* Input parity errors */ > >> }; > >> > >> for a random ancient driver. Introducing a third set of data structures > >> and syscalls for aarch64-ilp32 means that any driver doing something like > >> this needs to be modified to support existing user space source code. > > > > That's indeed a problem as ILP32 doesn't look like any of the other > > options (the siginfo structure is another case that doesn't fit in any > > of the ABI as long as time_t is 64-bit). > > I believe we?ve already arrived at the conclusion that timespec needs to be > changed from what Andrew and I had submitted. > > Let?s go back to the underlying definition of timespec: > "The range and precision of times representable in clock_t and time_t are > implementation-defined. The timespec structure shall contain at least the > following members, in any order. > > time_t tv_sec; // whole seconds -- >= 0 > long tv_nsec; // nanoseconds -- [0, 999999999]? > > So tv_nsec needs to be 32bit on ILP32, as we would otherwise break the C > language. Any program that assumes that tv_nsec is sizeof(long) would be > correct and it would be unexpected and surprising behaviour [even though it > would be consider a good programming style] if one would need to explicitly > ask for the sizeof(ts.tv_nsec). Having the same problem on x32 doesn?t seem > like a good justification to do the same. I don't think assuming that people who don't write 64-bit safe code write code that follows C11 is realistic ;-) A lot more code is broken by having a 64-bit time_t than would be broken by making tv_nsec 64-bit. > For time_t, I don?t see the need to have a 32bit type yet. > As long as the the type is properly exposed through header files (and user > programs can thus recreate the kernel?s data model), we should be safe. > > Cases like the above data structure from an ioctl are clearly non-portable > and would break today on any architecture that supports ABIs with different > data models (say ILP32 and LP64)? so I would consider any attempt to > support this as trying to remain ?bug-compatible?. > > There are plenty of good examples in the uapi that will be nicely portable > between ILP32 and LP64. Let?s take aio_abi.h (I?ve intentionally chosen this, > as the userspace library libaio uses a broken redefinition instead of the > kernel header file) as an example: > > /* > > ... structures that done in modern times by competent developers should all be the same across the three ABIs, no need to worry about that. The only worrying part is drivers that are written in an incompatible form for whatever reason. These have become rarer in the recent years, but we still see new ones getting merged, e.g. the Android binder. > The key to any design decision should be that we > (a) don?t break C11, POSIX or the Single UNIX Specification > (b) remain true to the definitions from the the AArch64 ILP32 ELF ABI > (which defines 64bit values transferable in registers to callees) These are nice goals, but I don't think they primary objectives. Getting things to work is much more important, and the timespec definition among other things may end up not being standards compliant in order to get there. > Can we thus agree on the following for the next revision of the patch-set: > (1) We retain a 64bit time_t, but implement different sizes (between ILP32 and > LP64) for ?tv_nsec' in 'struct timespec?? I have a plan for addressing that, but it will likely take another year before we can get consensus on the timespec layout for 64-bit time_t. At the moment, it looks like the 64/64 layout has more support than the 64/pad/32 layout you are describing. Let's not rush this for aarch64 when there is a chance that we end up with a different layout on native 32-bit machines. > (2) We use the 64bit system calls whereever possible (i.e. no register splitting). I'm fine with using 64-bit registers for passing loff_t if we use the asm-generic/unistd.h system call numbers. Arnd
next prev parent reply other threads:[~2015-04-15 12:43 UTC|newest] Thread overview: 155+ messages / expand[flat|nested] mbox.gz Atom feed top 2015-04-13 19:44 [PATCH v4 00/24] ILP32 for ARM64 Philipp Tomsich 2015-04-13 19:44 ` Philipp Tomsich 2015-04-13 19:44 ` [PATCH v4 01/24] arm64:ilp32: add documentation on the ILP32 ABI " Philipp Tomsich 2015-04-13 19:44 ` Philipp Tomsich 2015-04-13 19:44 ` [PATCH v4 02/24] arm64: ensure the kernel is compiled for LP64 Philipp Tomsich 2015-04-13 19:44 ` Philipp Tomsich 2015-04-13 19:44 ` [PATCH v4 03/24] arm64: rename COMPAT to AARCH32_EL0 in Kconfig Philipp Tomsich 2015-04-13 19:44 ` Philipp Tomsich 2015-04-13 19:44 ` [PATCH v4 04/24] arm64: change some CONFIG_COMPAT over to use CONFIG_AARCH32_EL0 instead Philipp Tomsich 2015-04-13 19:44 ` Philipp Tomsich 2015-04-13 19:44 ` [PATCH v4 05/24] arm64:ilp32: expose 'kernel_long' as 'long long' for ILP32 Philipp Tomsich 2015-04-13 19:44 ` Philipp Tomsich 2015-04-13 19:44 ` [PATCH v4 06/24] arm64:uapi: set __BITS_PER_LONG correctly for ILP32 and LP64 Philipp Tomsich 2015-04-13 19:44 ` Philipp Tomsich 2015-04-13 19:44 ` [PATCH v4 07/24] arm64:ilp32: share signal structures between ILP32 and LP64 ABIs Philipp Tomsich 2015-04-13 19:44 ` Philipp Tomsich 2015-04-13 19:44 ` [PATCH v4 08/24] arm64:ilp32: use 64bit syscall-names for ILP32 when passing 64bit registers Philipp Tomsich 2015-04-13 19:44 ` Philipp Tomsich 2015-04-13 19:44 ` [PATCH v4 09/24] arm64:ilp32: use non-compat syscall names for ILP32 as for LP64 Philipp Tomsich 2015-04-13 19:44 ` Philipp Tomsich 2015-04-13 19:44 ` [PATCH v4 10/24] arm64: introduce is_a32_task and is_a32_thread (for AArch32 compat) Philipp Tomsich 2015-04-13 19:44 ` Philipp Tomsich 2015-04-13 19:44 ` [PATCH v4 11/24] arm64:ilp32: add is_ilp32_compat_{task,thread} and TIF_32BIT_AARCH64 Philipp Tomsich 2015-04-13 19:44 ` [PATCH v4 11/24] arm64:ilp32: add is_ilp32_compat_{task, thread} " Philipp Tomsich 2015-04-13 19:44 ` [PATCH v4 12/24] arm64:ilp32: COMPAT_USE_64BIT_TIME is true for ILP32 tasks Philipp Tomsich 2015-04-13 19:44 ` Philipp Tomsich 2015-04-13 19:44 ` [PATCH v4 13/24] arm64:ilp32: share HWCAP between LP64 and ILP32 Philipp Tomsich 2015-04-13 19:44 ` Philipp Tomsich 2015-04-13 19:44 ` [PATCH v4 14/24] arm64:ilp32 use the native LP64 'start_thread' for ILP32 threads Philipp Tomsich 2015-04-13 19:44 ` Philipp Tomsich 2015-04-13 19:44 ` [PATCH v4 15/24] arm64:ilp32: support core dump generation for ILP32 Philipp Tomsich 2015-04-13 19:44 ` Philipp Tomsich 2015-04-13 19:44 ` [PATCH v4 16/24] arm64: add support for starting ILP32 (ELFCLASS32) binaries Philipp Tomsich 2015-04-13 19:44 ` Philipp Tomsich 2015-04-13 19:44 ` [PATCH v4 17/24] arm64:ilp32: add vdso-ilp32 and use for signal return Philipp Tomsich 2015-04-13 19:44 ` Philipp Tomsich 2015-04-13 19:44 ` [PATCH v4 18/24] ptrace: Allow compat to use the native siginfo Philipp Tomsich 2015-04-13 19:44 ` Philipp Tomsich 2015-04-13 19:44 ` [PATCH v4 19/24] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it Philipp Tomsich 2015-04-13 19:44 ` Philipp Tomsich 2015-04-13 19:44 ` [PATCH v4 20/24] arm64:ilp32: use compat-syscalls for msgsnd and msgrcv for ILP32 Philipp Tomsich 2015-04-13 19:44 ` Philipp Tomsich 2015-04-13 19:44 ` [PATCH v4 21/24] arm64:ilp32: use the native siginfo instead of the compat siginfo Philipp Tomsich 2015-04-13 19:44 ` Philipp Tomsich 2015-04-13 19:44 ` [PATCH v4 22/24] arm64:ilp32: use compat for stack_t Philipp Tomsich 2015-04-13 19:44 ` Philipp Tomsich 2015-05-05 0:03 ` Pinski, Andrew 2015-05-05 0:03 ` Pinski, Andrew 2015-04-13 19:44 ` [PATCH v4 23/24] arm64:ilp32: change COMPAT_ELF_PLATFORM to report a a subplatform for ILP32 Philipp Tomsich 2015-04-13 19:44 ` Philipp Tomsich 2015-04-13 19:44 ` [PATCH v4 24/24] arm64:ilp32: add ARM64_ILP32 to Kconfig Philipp Tomsich 2015-04-13 19:44 ` Philipp Tomsich 2015-04-13 21:01 ` [PATCH v4 00/24] ILP32 for ARM64 Arnd Bergmann 2015-04-13 21:01 ` Arnd Bergmann 2015-04-13 22:58 ` Dr. Philipp Tomsich 2015-04-13 22:58 ` Dr. Philipp Tomsich 2015-04-14 9:33 ` Dr. Philipp Tomsich 2015-04-14 10:08 ` Arnd Bergmann 2015-04-14 10:08 ` Arnd Bergmann 2015-04-14 10:45 ` Pinski, Andrew 2015-04-14 10:45 ` Pinski, Andrew 2015-04-14 11:14 ` Arnd Bergmann 2015-04-14 11:14 ` Arnd Bergmann 2015-04-14 11:50 ` Dr. Philipp Tomsich 2015-04-14 11:50 ` Dr. Philipp Tomsich 2015-04-14 14:07 ` Arnd Bergmann 2015-04-14 14:07 ` Arnd Bergmann 2015-04-14 14:54 ` Dr. Philipp Tomsich 2015-04-15 12:25 ` Arnd Bergmann 2015-04-15 12:25 ` Arnd Bergmann 2015-04-14 15:00 ` Catalin Marinas 2015-04-14 15:00 ` Catalin Marinas 2015-04-14 22:28 ` Arnd Bergmann 2015-04-14 22:28 ` Arnd Bergmann 2015-04-15 9:18 ` Dr. Philipp Tomsich 2015-04-15 9:18 ` Dr. Philipp Tomsich 2015-04-15 10:01 ` Catalin Marinas 2015-04-15 10:01 ` Catalin Marinas 2015-04-15 15:15 ` Arnd Bergmann 2015-04-15 15:15 ` Arnd Bergmann 2015-04-15 15:38 ` Catalin Marinas 2015-04-15 15:38 ` Catalin Marinas 2015-04-15 17:01 ` Dr. Philipp Tomsich 2015-04-15 17:01 ` Dr. Philipp Tomsich 2015-04-15 17:22 ` Catalin Marinas 2015-04-15 17:22 ` Catalin Marinas 2015-04-15 22:25 ` Alexander Graf 2015-04-15 22:25 ` Alexander Graf 2015-04-16 11:03 ` Catalin Marinas 2015-04-16 11:03 ` Catalin Marinas 2015-04-16 11:19 ` Dr. Philipp Tomsich 2015-04-16 11:19 ` Dr. Philipp Tomsich 2015-04-16 11:33 ` Pinski, Andrew 2015-04-16 11:33 ` Pinski, Andrew 2015-04-16 13:31 ` Catalin Marinas 2015-04-16 13:31 ` Catalin Marinas 2015-04-16 15:21 ` Arnd Bergmann 2015-04-16 15:21 ` Arnd Bergmann 2015-04-17 9:01 ` Catalin Marinas 2015-04-17 9:01 ` Catalin Marinas 2015-04-17 13:17 ` Arnd Bergmann 2015-04-17 13:17 ` Arnd Bergmann 2015-04-17 14:06 ` Alexander Graf 2015-04-17 14:06 ` Alexander Graf 2015-04-17 14:46 ` Catalin Marinas 2015-04-17 14:46 ` Catalin Marinas 2015-04-17 15:15 ` Dr. Philipp Tomsich 2015-04-17 15:15 ` Dr. Philipp Tomsich 2015-04-18 19:24 ` Arnd Bergmann 2015-04-18 19:24 ` Arnd Bergmann 2015-05-04 10:29 ` Arnd Bergmann 2015-05-04 10:29 ` Arnd Bergmann 2015-05-04 10:32 ` Dr. Philipp Tomsich 2015-05-04 10:32 ` Dr. Philipp Tomsich 2015-05-04 14:43 ` Arnd Bergmann 2015-05-04 14:43 ` Arnd Bergmann 2015-05-05 13:11 ` Arnd Bergmann 2015-05-05 13:11 ` Arnd Bergmann 2015-04-17 15:49 ` Arnd Bergmann 2015-04-17 15:49 ` Arnd Bergmann 2015-04-20 15:56 ` Catalin Marinas 2015-04-20 15:56 ` Catalin Marinas 2015-04-20 17:40 ` Arnd Bergmann 2015-04-20 17:40 ` Arnd Bergmann 2015-04-20 14:37 ` Zhangjian (Bamvor) 2015-04-20 14:37 ` Zhangjian (Bamvor) 2015-04-16 14:27 ` Catalin Marinas 2015-04-16 14:27 ` Catalin Marinas 2015-04-14 11:51 ` Pinski, Andrew 2015-04-14 11:51 ` Pinski, Andrew 2015-04-14 14:56 ` Catalin Marinas 2015-04-14 14:56 ` Catalin Marinas 2015-04-14 13:38 ` Catalin Marinas 2015-04-14 13:38 ` Catalin Marinas 2015-04-14 14:47 ` Catalin Marinas 2015-04-14 14:47 ` Catalin Marinas 2015-04-14 15:29 ` Dr. Philipp Tomsich 2015-04-14 15:29 ` Dr. Philipp Tomsich 2015-04-14 16:55 ` Catalin Marinas 2015-04-14 16:55 ` Catalin Marinas 2015-04-15 10:31 ` Dr. Philipp Tomsich 2015-04-15 10:31 ` Dr. Philipp Tomsich 2015-04-15 12:47 ` Arnd Bergmann 2015-04-15 12:47 ` Arnd Bergmann 2015-04-15 12:42 ` Arnd Bergmann [this message] 2015-04-15 12:42 ` Arnd Bergmann 2015-04-14 15:44 ` Arnd Bergmann 2015-04-14 15:44 ` Arnd Bergmann 2015-04-15 11:22 ` Catalin Marinas 2015-04-15 11:22 ` Catalin Marinas 2015-04-15 11:50 ` Dr. Philipp Tomsich 2015-04-15 15:49 ` Catalin Marinas 2015-04-15 15:49 ` Catalin Marinas 2015-04-14 9:40 ` Arnd Bergmann 2015-04-14 9:40 ` 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=12636371.MavevVFsON@wuerfel \ --to=arnd@arndb.de \ --cc=andreas.kraschitzer@theobroma-systems.com \ --cc=apinski@cavium.com \ --cc=benedikt.huber@theobroma-systems.com \ --cc=catalin.marinas@arm.com \ --cc=christoph.muellner@theobroma-systems.com \ --cc=ksankaran@apm.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=philipp.tomsich@theobroma-systems.com \ /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: linkBe 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.