From: Thorsten Glaser <tg@mirbsd.de> To: Arnd Bergmann <arnd@arndb.de> Cc: y2038@lists.linaro.org, klibc@zytor.com, libc-alpha@sourceware.org, linux-api@vger.kernel.org, musl@lists.openwall.com, linux-kernel@vger.kernel.org, Rich Felker <dalias@libc.org>, cferris@google.com, enh@google.com, "Joseph S. Myers" <joseph@codesourcery.com> Subject: Re: [Y2038] [klibc] kernel/libc uapi changes for y2038 Date: Mon, 18 May 2015 17:03:08 +0000 (UTC) [thread overview] Message-ID: <Pine.BSM.4.64L.1505181658330.32668@herc.mirbsd.org> (raw) In-Reply-To: <10173485.f8yUt0lQ60@wuerfel> fup2p, this is offtopic for most lists Arnd Bergmann dixit: >It's hard because we don't even know what ioctls are affected at this point, >and I was hoping to get this part merged as a stepping stone in the process >of finding out. Oh okay. >e) ioctls that pass a time value as a 'long' or '__u32' instead of > 'time_t'. Fixing them requires adding new ioctl commands to let > them work beyond 2038, independent of what we do here. Yeah, that’s going to be fun. >MIPS on the other hand is no more broken than any of the other 32-bit >ABIs, because it does not use 64-bit __kernel_long_t in its n32 ABI. I have heard from a MIPS porter that one of the flavours suffers from similar problems as x32, just not to that extent. But I don’t recall my source… >ioctls. My plan at this point is to eliminate all uses of time_t in >the kernel and replace them with time64_t or other safe types. >This way, we will eventually find all code that passes 32-bit time types >to user space and can fix it. This will take care of the time_t >related problems on x32 as well. Ah, interesting approach. And existing userspace, as well as new userspace that does not declare 64-bit time_t readiness, is still safe on currently-not-broken architectures? So, there’s enough time to fix this before the various libcs turn that on (and it had better be fixed by then, because it becomes ABI by then). Nice idea. I am wondering a bit about the ioctls being hard to find. I have not much experience with kernel programming, and even less with Linux than with MS-DOS and BSD, but should not each driver have a central ioctl entry point, from which it should cast the user space data into a (possibly locally declared) structure? bye, //mirabilos -- <igli> exceptions: a truly awful implementation of quite a nice idea. <igli> just about the worst way you could do something like that, afaic. <igli> it's like anti-design. <mirabilos> that too… may I quote you on that? <igli> sure, tho i doubt anyone will listen ;)
WARNING: multiple messages have this Message-ID (diff)
From: Thorsten Glaser <tg@mirbsd.de> To: Arnd Bergmann <arnd@arndb.de> Cc: klibc@zytor.com, libc-alpha@sourceware.org, y2038@lists.linaro.org, linux-api@vger.kernel.org, musl@lists.openwall.com, linux-kernel@vger.kernel.org, Rich Felker <dalias@libc.org>, cferris@google.com, enh@google.com, "Joseph S. Myers" <joseph@codesourcery.com> Subject: Re: [klibc] kernel/libc uapi changes for y2038 Date: Mon, 18 May 2015 17:03:08 +0000 (UTC) [thread overview] Message-ID: <Pine.BSM.4.64L.1505181658330.32668@herc.mirbsd.org> (raw) In-Reply-To: <10173485.f8yUt0lQ60@wuerfel> fup2p, this is offtopic for most lists Arnd Bergmann dixit: >It's hard because we don't even know what ioctls are affected at this point, >and I was hoping to get this part merged as a stepping stone in the process >of finding out. Oh okay. >e) ioctls that pass a time value as a 'long' or '__u32' instead of > 'time_t'. Fixing them requires adding new ioctl commands to let > them work beyond 2038, independent of what we do here. Yeah, that’s going to be fun. >MIPS on the other hand is no more broken than any of the other 32-bit >ABIs, because it does not use 64-bit __kernel_long_t in its n32 ABI. I have heard from a MIPS porter that one of the flavours suffers from similar problems as x32, just not to that extent. But I don’t recall my source… >ioctls. My plan at this point is to eliminate all uses of time_t in >the kernel and replace them with time64_t or other safe types. >This way, we will eventually find all code that passes 32-bit time types >to user space and can fix it. This will take care of the time_t >related problems on x32 as well. Ah, interesting approach. And existing userspace, as well as new userspace that does not declare 64-bit time_t readiness, is still safe on currently-not-broken architectures? So, there’s enough time to fix this before the various libcs turn that on (and it had better be fixed by then, because it becomes ABI by then). Nice idea. I am wondering a bit about the ioctls being hard to find. I have not much experience with kernel programming, and even less with Linux than with MS-DOS and BSD, but should not each driver have a central ioctl entry point, from which it should cast the user space data into a (possibly locally declared) structure? bye, //mirabilos -- <igli> exceptions: a truly awful implementation of quite a nice idea. <igli> just about the worst way you could do something like that, afaic. <igli> it's like anti-design. <mirabilos> that too… may I quote you on that? <igli> sure, tho i doubt anyone will listen ;) _______________________________________________ Y2038 mailing list Y2038@lists.linaro.org https://lists.linaro.org/mailman/listinfo/y2038
next prev parent reply other threads:[~2015-05-18 17:04 UTC|newest] Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top 2015-05-18 9:53 kernel/libc uapi changes for y2038 Arnd Bergmann 2015-05-18 12:16 ` [klibc] " Thorsten Glaser 2015-05-18 12:16 ` Thorsten Glaser 2015-05-18 13:32 ` [Y2038] " Arnd Bergmann 2015-05-18 17:03 ` Thorsten Glaser [this message] 2015-05-18 17:03 ` Thorsten Glaser 2015-05-18 20:35 ` [Y2038] " Arnd Bergmann 2015-05-18 20:35 ` Arnd Bergmann 2015-05-19 17:54 ` [Y2038] " John Stultz 2015-05-27 15:28 ` [klibc] " H. Peter Anvin 2015-05-27 20:19 ` Arnd Bergmann 2015-05-27 20:19 ` 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=Pine.BSM.4.64L.1505181658330.32668@herc.mirbsd.org \ --to=tg@mirbsd.de \ --cc=arnd@arndb.de \ --cc=cferris@google.com \ --cc=dalias@libc.org \ --cc=enh@google.com \ --cc=joseph@codesourcery.com \ --cc=klibc@zytor.com \ --cc=libc-alpha@sourceware.org \ --cc=linux-api@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=musl@lists.openwall.com \ --cc=y2038@lists.linaro.org \ /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.