From: Catalin Marinas <catalin.marinas@arm.com> To: "Dr. Philipp Tomsich" <philipp.tomsich@theobroma-systems.com> Cc: Andreas Kraschitzer <andreas.kraschitzer@theobroma-systems.com>, Arnd Bergmann <arnd@arndb.de>, linux-kernel@vger.kernel.org, Andrew Pinski <apinski@cavium.com>, Kumar Sankaran <ksankaran@apm.com>, Benedikt Huber <benedikt.huber@theobroma-systems.com>, linux-arm-kernel <linux-arm-kernel@lists.infradead.org>, Christoph Muellner <christoph.muellner@theobroma-systems.com> Subject: Re: [PATCH v4 00/24] ILP32 for ARM64 Date: Tue, 14 Apr 2015 17:55:00 +0100 [thread overview] Message-ID: <20150414165459.GG14546@e104818-lin.cambridge.arm.com> (raw) In-Reply-To: <9F7FC15C-EED1-4939-B66A-1BC3119E0D9C@theobroma-systems.com> On Tue, Apr 14, 2015 at 05:29:36PM +0200, 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. >From a standards perspective, that's clear, and I'm fine with not making the same choice as x32. I think on x32 it was a side-effect of glibc defining tv_nsec as __syscall_slong_t and the kernel defining __kernel_long_t to 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. The problem with a 64-bit time_t is that the timespec structure looks like neither compat32 nor native 64-bit. If we make the AArch32 and native ILP32 exclusive and build time, it makes it easier, otherwise we need to support a third ABI in the kernel. > 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) I think these are fine. > 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’? > (2) We use the 64bit system calls whereever possible (i.e. no register splitting). As I mentioned above, timespec and possibly other structures no longer like any of the existing ABIs. Do we know how many syscalls are affected? The alternative is 32-bit time_t which makes it easier to use the compat syscall implementations (not numbers). It also depends on how we plan to fix the 2038 problem. For new 32-bit only architectures, are we going to require them to use a 64-bit time_t or we get alternative time64_t and timespec64 specs? -- Catalin
WARNING: multiple messages have this Message-ID (diff)
From: catalin.marinas@arm.com (Catalin Marinas) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH v4 00/24] ILP32 for ARM64 Date: Tue, 14 Apr 2015 17:55:00 +0100 [thread overview] Message-ID: <20150414165459.GG14546@e104818-lin.cambridge.arm.com> (raw) In-Reply-To: <9F7FC15C-EED1-4939-B66A-1BC3119E0D9C@theobroma-systems.com> On Tue, Apr 14, 2015 at 05:29:36PM +0200, 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. >From a standards perspective, that's clear, and I'm fine with not making the same choice as x32. I think on x32 it was a side-effect of glibc defining tv_nsec as __syscall_slong_t and the kernel defining __kernel_long_t to 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. The problem with a 64-bit time_t is that the timespec structure looks like neither compat32 nor native 64-bit. If we make the AArch32 and native ILP32 exclusive and build time, it makes it easier, otherwise we need to support a third ABI in the kernel. > 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) I think these are fine. > 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?? > (2) We use the 64bit system calls whereever possible (i.e. no register splitting). As I mentioned above, timespec and possibly other structures no longer like any of the existing ABIs. Do we know how many syscalls are affected? The alternative is 32-bit time_t which makes it easier to use the compat syscall implementations (not numbers). It also depends on how we plan to fix the 2038 problem. For new 32-bit only architectures, are we going to require them to use a 64-bit time_t or we get alternative time64_t and timespec64 specs? -- Catalin
next prev parent reply other threads:[~2015-04-14 16:55 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 [this message] 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 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=20150414165459.GG14546@e104818-lin.cambridge.arm.com \ --to=catalin.marinas@arm.com \ --cc=andreas.kraschitzer@theobroma-systems.com \ --cc=apinski@cavium.com \ --cc=arnd@arndb.de \ --cc=benedikt.huber@theobroma-systems.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.