From: Catalin Marinas <catalin.marinas@arm.com> To: "Pinski, Andrew" <Andrew.Pinski@caviumnetworks.com> Cc: "Dr. Philipp Tomsich" <philipp.tomsich@theobroma-systems.com>, Andreas Kraschitzer <andreas.kraschitzer@theobroma-systems.com>, Arnd Bergmann <arnd@arndb.de>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, Alexander Graf <agraf@suse.de>, Andrew Pinski <apinski@cavium.com>, Andreas Schwab <schwab@suse.de>, Kumar Sankaran <ksankaran@apm.com>, Benedikt Huber <benedikt.huber@theobroma-systems.com>, "linux-arm-kernel@lists.infradead.org" <linux-arm-kernel@lists.infradead.org>, Christoph Muellner <christoph.muellner@theobroma-systems.com> Subject: Re: [PATCH v4 00/24] ILP32 for ARM64 Date: Thu, 16 Apr 2015 14:31:34 +0100 [thread overview] Message-ID: <20150416133134.GC819@e104818-lin.cambridge.arm.com> (raw) In-Reply-To: <E769538B-CE45-4FF3-AD2C-21B30069F0B9@caviumnetworks.com> On Thu, Apr 16, 2015 at 11:33:49AM +0000, Pinski, Andrew wrote: > On Apr 16, 2015, at 4:19 AM, Dr. Philipp Tomsich <philipp.tomsich@theobroma-systems.com> wrote: > > Just for the record (and to avoid anyone wasting their time on what’s available > > today): we are migrating this over to option (a) now, even though we would > > prefer to see option (b) implemented. > > > > If we get a consensus on (b) in the next couple of days, we’ll redo things for > > option (b). If not, we will have an implementation for option (a) available that > > we can hopefully all agree on merging. > > I don't think either a or b are good in the long run. b would have been my preferred option if it wasn't for the legacy apps support. We could also do it without much hassle in the kernel *if* we disabled AArch32 compat support (basically use the compat layer for ILP32). But I don't think choosing between AArch32 and AArch64 ILP32 should be a build time option. > There are only a few places where long should be 32bit rather than > 64bit. The non-time_t field of timespec is the only one I can think > of. It may be the only one but we could end up with a non-compliant timespec. Unless we keep the tv_nsec as 32-bit long and add some padding, we could work around it by getting the C library to sign-extend such padding or we do it in a new "compat" layer in the kernel (but both cases imply copying the structure). However, timerspec is included in other structures, so we'd have to intercept those as well. Philipp provided a list here: http://article.gmane.org/gmane.linux.kernel/1931497 > The rest are valid and good idea to stay as 64bit. Including the > limits. I think this whole discussion should have happened over a year > ago. And I thought c was decided back then. I had even implemented a > originally and then asked to move over to c. So I am a bit upset now > we are making this kind of huge changes to the abi a year after the > original posting of the patch. Well, I said it already, this ABI is *not* a kernel-only decision, so without further feedback from the user space world I'm not merging any patches. I thought I was pretty clear 6-7 months ago but there wasn't any reply until February: http://article.gmane.org/gmane.linux.kernel/1800005 > Also why does it takes over a year to accept patches into the linux > kernel when it takes much less time to make huge changes into gcc Original developers being unresponsive could be a reason ;) (see the above post unanswered for few months). > (pointer plus is an example which took only a few months to accept and > it was an infrastructure change and this is not even an infrastructure > change). ILP32 is an ABI that we have to leave with for many years. We have to try hard to get it right rather than rush merging the patches (once merged, we can't break the ABI later). -- 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: Thu, 16 Apr 2015 14:31:34 +0100 [thread overview] Message-ID: <20150416133134.GC819@e104818-lin.cambridge.arm.com> (raw) In-Reply-To: <E769538B-CE45-4FF3-AD2C-21B30069F0B9@caviumnetworks.com> On Thu, Apr 16, 2015 at 11:33:49AM +0000, Pinski, Andrew wrote: > On Apr 16, 2015, at 4:19 AM, Dr. Philipp Tomsich <philipp.tomsich@theobroma-systems.com> wrote: > > Just for the record (and to avoid anyone wasting their time on what?s available > > today): we are migrating this over to option (a) now, even though we would > > prefer to see option (b) implemented. > > > > If we get a consensus on (b) in the next couple of days, we?ll redo things for > > option (b). If not, we will have an implementation for option (a) available that > > we can hopefully all agree on merging. > > I don't think either a or b are good in the long run. b would have been my preferred option if it wasn't for the legacy apps support. We could also do it without much hassle in the kernel *if* we disabled AArch32 compat support (basically use the compat layer for ILP32). But I don't think choosing between AArch32 and AArch64 ILP32 should be a build time option. > There are only a few places where long should be 32bit rather than > 64bit. The non-time_t field of timespec is the only one I can think > of. It may be the only one but we could end up with a non-compliant timespec. Unless we keep the tv_nsec as 32-bit long and add some padding, we could work around it by getting the C library to sign-extend such padding or we do it in a new "compat" layer in the kernel (but both cases imply copying the structure). However, timerspec is included in other structures, so we'd have to intercept those as well. Philipp provided a list here: http://article.gmane.org/gmane.linux.kernel/1931497 > The rest are valid and good idea to stay as 64bit. Including the > limits. I think this whole discussion should have happened over a year > ago. And I thought c was decided back then. I had even implemented a > originally and then asked to move over to c. So I am a bit upset now > we are making this kind of huge changes to the abi a year after the > original posting of the patch. Well, I said it already, this ABI is *not* a kernel-only decision, so without further feedback from the user space world I'm not merging any patches. I thought I was pretty clear 6-7 months ago but there wasn't any reply until February: http://article.gmane.org/gmane.linux.kernel/1800005 > Also why does it takes over a year to accept patches into the linux > kernel when it takes much less time to make huge changes into gcc Original developers being unresponsive could be a reason ;) (see the above post unanswered for few months). > (pointer plus is an example which took only a few months to accept and > it was an infrastructure change and this is not even an infrastructure > change). ILP32 is an ABI that we have to leave with for many years. We have to try hard to get it right rather than rush merging the patches (once merged, we can't break the ABI later). -- Catalin
next prev parent reply other threads:[~2015-04-16 13:31 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 [this message] 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 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=20150416133134.GC819@e104818-lin.cambridge.arm.com \ --to=catalin.marinas@arm.com \ --cc=Andrew.Pinski@caviumnetworks.com \ --cc=agraf@suse.de \ --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 \ --cc=schwab@suse.de \ /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.