diff for duplicates of <20150415100153.GA11626@localhost> diff --git a/a/1.txt b/N1/1.txt index 8e86b84..fd9a553 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -18,7 +18,7 @@ On Wed, Apr 15, 2015 at 11:18:06AM +0200, Dr. Philipp Tomsich wrote: > > want to run a full system for this and need POSIX compliance. > > I strongly disagree on this: ILP32 is a first-class citizen of the ARMv8 -> ecosystem as a ?data-model? for AArch64. Having a corresponding Linux +> ecosystem as a “data-model” for AArch64. Having a corresponding Linux > syscall ABI is necessitated because not all data structures shared across > the syscall-boundary are describted/defined in data-model agnostic types. > ILP32 thus has the same importance as the LP64 ABI in ARMv8. It is thus @@ -43,8 +43,8 @@ marketing exercise for CPUs not supporting AArch32. (if anyone has more feedback on commercial needs for ILP32, please let us know, even if it is in private) -> 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. @@ -59,24 +59,24 @@ like it regularly happens with big endian). > > not easier. > > 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. -> Consequently, I don?t necessarily see the value in defining ILP32 for +> Consequently, I don’t necessarily see the value in defining ILP32 for > AArch64 with a 32bit time_t (even though it would be simpler at this -> moment), as I don?t see the benefit of adding a new ABI that propagates -> a well known problem (even if one could argue that there?s plenty of time +> moment), as I don’t see the benefit of adding a new ABI that propagates +> a well known problem (even if one could argue that there’s plenty of time > to fix this by 2038). We could look at this in a different way: time_t should be the same size diff --git a/a/content_digest b/N1/content_digest index 765c36e..d6bdb48 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -3,10 +3,20 @@ "ref\020150414150034.GF14546@e104818-lin.cambridge.arm.com\0" "ref\02947000.5TRODaJfhK@wuerfel\0" "ref\0025BB233-8D14-457A-B3B2-C6BD6C3B32EF@theobroma-systems.com\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 11:01:54 +0100\0" - "To\0linux-arm-kernel@lists.infradead.org\0" + "To\0Dr. Philipp Tomsich <philipp.tomsich@theobroma-systems.com>\0" + "Cc\0Arnd Bergmann <arnd@arndb.de>" + Andreas Kraschitzer <andreas.kraschitzer@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> + Benedikt Huber <benedikt.huber@theobroma-systems.com> + linux-arm-kernel <linux-arm-kernel@lists.infradead.org> + " Christoph Muellner <christoph.muellner@theobroma-systems.com>\0" "\00:1\0" "b\0" "On Wed, Apr 15, 2015 at 11:18:06AM +0200, Dr. Philipp Tomsich wrote:\n" @@ -29,7 +39,7 @@ "> > want to run a full system for this and need POSIX compliance.\n" "> \n" "> I strongly disagree on this: ILP32 is a first-class citizen of the ARMv8 \n" - "> ecosystem as a ?data-model? for AArch64. Having a corresponding Linux \n" + "> ecosystem as a \342\200\234data-model\342\200\235 for AArch64. Having a corresponding Linux \n" "> syscall ABI is necessitated because not all data structures shared across\n" "> the syscall-boundary are describted/defined in data-model agnostic types.\n" "> ILP32 thus has the same importance as the LP64 ABI in ARMv8. It is thus \n" @@ -54,8 +64,8 @@ "(if anyone has more feedback on commercial needs for ILP32, please let\n" "us know, even if it is in private)\n" "\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" @@ -70,24 +80,24 @@ "> > not easier.\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" "\n" - "> Consequently, I don?t necessarily see the value in defining ILP32 for\n" + "> Consequently, I don\342\200\231t necessarily see the value in defining ILP32 for\n" "> AArch64 with a 32bit time_t (even though it would be simpler at this \n" - "> moment), as I don?t see the benefit of adding a new ABI that propagates\n" - "> a well known problem (even if one could argue that there?s plenty of time\n" + "> moment), as I don\342\200\231t see the benefit of adding a new ABI that propagates\n" + "> a well known problem (even if one could argue that there\342\200\231s plenty of time\n" "> to fix this by 2038).\n" "\n" "We could look at this in a different way: time_t should be the same size\n" @@ -101,4 +111,4 @@ "-- \n" Catalin -6b5ea189a92662a18963fb8b812bfa6577529fb41dd1b730c9fbad93bc6a3c26 +30982f65cfacad0936fe6e11430f29afedcc2d9e7045b3ace7de1616c6bf00f4
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.