This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [Y2038] [klibc] kernel/libc uapi changes for y2038
- From: Thorsten Glaser <tg at mirbsd dot de>
- To: Arnd Bergmann <arnd at arndb dot de>
- Cc: y2038 at lists dot linaro dot org, klibc at zytor dot com, libc-alpha at sourceware dot org, linux-api at vger dot kernel dot org, musl at lists dot openwall dot com, linux-kernel at vger dot kernel dot org, Rich Felker <dalias at libc dot org>, cferris at google dot com, enh at google dot com, "Joseph S. Myers" <joseph at codesourcery dot com>
- Date: Mon, 18 May 2015 17:03:08 +0000 (UTC)
- Subject: Re: [Y2038] [klibc] kernel/libc uapi changes for y2038
- Authentication-results: sourceware.org; auth=none
- Followup-to: poster
- References: <2664016 dot bYZKg6FQqR at wuerfel> <Pine dot BSM dot 4 dot 64L dot 1505181214530 dot 8249 at herc dot mirbsd dot org> <10173485 dot f8yUt0lQ60 at 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 ;)