diff for duplicates of <20150415153800.GG22741@localhost> diff --git a/a/1.txt b/N1/1.txt index eeebb1e..a114960 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -1,8 +1,8 @@ On Wed, Apr 15, 2015 at 05:15:16PM +0200, Arnd Bergmann wrote: > On Wednesday 15 April 2015 11:01:54 Catalin Marinas wrote: > > On Wed, Apr 15, 2015 at 11:18:06AM +0200, Dr. Philipp Tomsich wrote: -> > > We?ve run full systems (built from buildroot) consisting of ILP32 binaries -> > > only (ok? admittedly gdb was an exception, as we haven?t fixed the fact +> > > We’ve run full systems (built from buildroot) consisting of ILP32 binaries +> > > only (ok… admittedly gdb was an exception, as we haven’t fixed the fact > > > that someone has assumed sizeof(long) == 8 in some data-structure of > > > the AArch64 backend there) in our verification runs. In fact, it will be very > > > special classes of applications that will need a 64bit address-space. @@ -27,16 +27,16 @@ like Debian rather than all the packages. As for the compiler, AFAIK aarch64-linux-gnu-* simply needs an option to build for ILP32. > > > The key question at this point seems to be whether we want to support -> > > ?legacy 32-bit applications? (i.e. ones that make assumption that are +> > > “legacy 32-bit applications” (i.e. ones that make assumption that are > > > not covered by the underlying type definitions or specifications) or whether -> > > we aim for ?well-formed 32-bit applications?. +> > > we aim for “well-formed 32-bit applications”. > > > -> > > To stay with the 'struct timespec?-example, the difference between the +> > > To stay with the 'struct timespec’-example, the difference between the > > > former and the latter would (among others) be that the former might > > > assume sizeof(long) == sizeof(time_t), whereas the latter is allowed to > > > except that sizeof(long) == sizeof(ts.tv_nsec). > > > -> > > I don?t believe in keeping compatibility for the former type of applications. +> > > I don’t believe in keeping compatibility for the former type of applications. > > > > That was one of the initial reasons I heard for AArch64-ILP32. So more > > mixed messages. diff --git a/a/content_digest b/N1/content_digest index 9961965..f98c3bc 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -2,17 +2,27 @@ "ref\0025BB233-8D14-457A-B3B2-C6BD6C3B32EF@theobroma-systems.com\0" "ref\020150415100153.GA11626@localhost\0" "ref\02243754.JW5bGY74bP@wuerfel\0" - "From\0catalin.marinas@arm.com (Catalin Marinas)\0" - "Subject\0[PATCH v4 00/24] ILP32 for ARM64\0" + "From\0Catalin Marinas <catalin.marinas@arm.com>\0" + "Subject\0Re: [PATCH v4 00/24] ILP32 for ARM64\0" "Date\0Wed, 15 Apr 2015 16:38:00 +0100\0" - "To\0linux-arm-kernel@lists.infradead.org\0" + "To\0Arnd Bergmann <arnd@arndb.de>\0" + "Cc\0linux-arm-kernel@lists.infradead.org" + Andreas Kraschitzer <andreas.kraschitzer@theobroma-systems.com> + Benedikt Huber <benedikt.huber@theobroma-systems.com> + Pinski + Andrew <Andrew.Pinski@caviumnetworks.com> + linux-kernel@vger.kernel.org <linux-kernel@vger.kernel.org> + Andrew Pinski <apinski@cavium.com> + Kumar Sankaran <ksankaran@apm.com> + Dr. Philipp Tomsich <philipp.tomsich@theobroma-systems.com> + " Christoph Muellner <christoph.muellner@theobroma-systems.com>\0" "\00:1\0" "b\0" "On Wed, Apr 15, 2015 at 05:15:16PM +0200, Arnd Bergmann wrote:\n" "> On Wednesday 15 April 2015 11:01:54 Catalin Marinas wrote:\n" "> > On Wed, Apr 15, 2015 at 11:18:06AM +0200, Dr. Philipp Tomsich wrote:\n" - "> > > We?ve run full systems (built from buildroot) consisting of ILP32 binaries\n" - "> > > only (ok? admittedly gdb was an exception, as we haven?t fixed the fact\n" + "> > > We\342\200\231ve run full systems (built from buildroot) consisting of ILP32 binaries\n" + "> > > only (ok\342\200\246 admittedly gdb was an exception, as we haven\342\200\231t fixed the fact\n" "> > > that someone has assumed sizeof(long) == 8 in some data-structure of\n" "> > > the AArch64 backend there) in our verification runs. In fact, it will be very \n" "> > > special classes of applications that will need a 64bit address-space.\n" @@ -37,16 +47,16 @@ "aarch64-linux-gnu-* simply needs an option to build for ILP32.\n" "\n" "> > > The key question at this point seems to be whether we want to support\n" - "> > > ?legacy 32-bit applications? (i.e. ones that make assumption that are\n" + "> > > \342\200\234legacy 32-bit applications\342\200\235 (i.e. ones that make assumption that are\n" "> > > not covered by the underlying type definitions or specifications) or whether\n" - "> > > we aim for ?well-formed 32-bit applications?.\n" + "> > > we aim for \342\200\234well-formed 32-bit applications\342\200\235.\n" "> > > \n" - "> > > To stay with the 'struct timespec?-example, the difference between the \n" + "> > > To stay with the 'struct timespec\342\200\231-example, the difference between the \n" "> > > former and the latter would (among others) be that the former might \n" "> > > assume sizeof(long) == sizeof(time_t), whereas the latter is allowed to\n" "> > > except that sizeof(long) == sizeof(ts.tv_nsec).\n" "> > > \n" - "> > > I don?t believe in keeping compatibility for the former type of applications.\n" + "> > > I don\342\200\231t believe in keeping compatibility for the former type of applications.\n" "> > \n" "> > That was one of the initial reasons I heard for AArch64-ILP32. So more\n" "> > mixed messages.\n" @@ -66,4 +76,4 @@ "-- \n" Catalin -56261dc2e49dcd0e6f37a6395860415300e3a78b47d4eab6670655e53f59e995 +c4d76a414b7d4c1311332037684264c6c4211bd1ee7482eec31d1dcf32fbe254
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.