Re: Y2038 - best way forward in Debian?
* Steve McIntyre:
> The kernel is *basically* fixed now. Internally, data structures
> should now be safe. There are a small number places where 32-bit time
> is still a thing, but it's in hand. A number of syscalls, ioctls,
> etc. have needed updates for the user-kernel interface level.
XFS is the elephant in the room, though.
> glibc is the place that needs to care about most of this.
I'm not so sure. I really do not want glibc to parse and rewrite
ioctl arguments and return values, or ancillary socket data.
> The glibc folks have taken an interesting approach.
>
> * 64-bit ABIs/architectures are already using 64-bit time_t
> throughout. The design is sane and so we should already be mostly
> safe here, modulo silly code bugs (we'll always have those!)
With the exception of utmp/utmpx, see __WORDSIZE_TIME64_COMPAT32 in
the headers. Unfortuantely, this also affects on-disk data
structures.
> * 32-bit ABIs/arches are more awkward. glibc will continue *by
> default* to use 32-bit time_t to keep compatibility with existing
> code. This will *not* be safe as we approach 2038.
>
> * 32-bit ABIs/arches *can* be told to use 64-bit time_t from glibc
> upwards, but this will of course affect the ABI. Embedded uses of
> time_t in libraries will change size, etc. This *will* be safe for
> 2038.
>
> So, we're all fine? Not so much: for our 32-bit Debian arches, we will
> need to basically rebuild the world to be 2038-safe.
The question is whether anyone wants an i386 port where this has
happened.
My opinion (professional in this case, even) is that i386 users want
compatibility with their binaries from 1998. Otherwise they would
have rebuilt them for x86-64 by now. Under this worldview, i386 is
for backwards compatibility with existing software. Users will want
to run these old programs in a time namespace with shifted time, too.
There is also substantial commercial interest in those old binaries
(which becomes apparent when you break glibc compatibility with them
8-/).
> B Decide which 32-bit ports we expect to care about by 2038, and
> re-bootstrap new versions of those ports *with different
> names*. This would allow most of our developers to ignore the
> problem here (as 64-bit arches are not affected) and let a smaller
> number of people re-bootstrap with new ABIs with 64-bit time_t
> embedded. There are some downsides here:
>
> * we would end up with two versions of some ports for a short time
> - probably one release of overlap
>
> * users would *not* be able to simply upgrade from one to the
> other, due to lack of binary compatibility
>
> We *would* be able to run old and new ABIs on top of the same (new
> enough) kernel (e.g. for buildds), so a lump of this would just be
> simply building the new world and filing bugs where needed.
>
> We'd need to decide exactly which of our 32-bit ports we would want
> to do this path with (probably armhf->arhmft?, maybe
> armel->armelt?, i386->i386t?. mipsel???). Due to the libc6 soname
> continuity, we will most likely *not* end up with a different
> visible ABI via the triplet and the runtime linker, so old/new
> multi-arch will be impossible.
Yes, it really has to be B for i386 at least.
The other issue is that the Y2038 work has tentacles everywhere.
Porting to new architectures (whether they are 32-bit or 64-bit) will
require additional changes to those applications which make direct
system calls, in some cases even if they do not even use time_t or
struct timespec with those system calls at all. For example, new
ports will not define __NR_futex, only __NR_futex_time64.
Reply to: