On Fri, Feb 7, 2020 at 10:21 PM Florian Weimer <f...@deneb.enyo.de> wrote:
>
> * 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.
XFS is one of the main concerns for 64-bit kernels, but the patches
are likely to get merged in one of the next releases.
For 32-bit, all the ABI issues need to be solved first to have
a working system at all, so let's get that sorted. Obviously all
problems that 64-bit has also need to be solved on 32-bit.
> > 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.
For a new distro target, it's easy to mandate a minimum kernel
version that has all the ioctls. Users that are stuck on old kernels
for a particular hardware can keep using the existing armhf user
space until that is discontinued.
> > * 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.
I agree that changing the i386 port is probably a bad idea at the moment,
let's see how the armhf port turns out and fix all the bugs first, as this
is clearly needed anyway. Once there is a working armhf version with
full time64 user space, there can be a separate discussion about what
to do with the i386 port (phase out i386 before y2038, migrate all of
i386 to time64 quickly, have two separate i386 ports, or something
else).
Arnd
