Re: Y2038 - best way forward in Debian?
Steve McIntyre <steve@einval.com> 于2020年2月4日周二 下午9:15写道：
>
> Hey folks,
>
> Apologies - I should have sent this mail quite a while back. :-/
>
> Arnd Bergmann (in CC) has been helping to drive a lot of work to solve
> the 2038 problem in the Linux world. I've spoken about this before,
> e.g. at DebConf17. He's been pushing a lot of updates throughout the
> Linux kernel, and has also been analysing code elsewhere. He's very
> interested in how to update complete systems like Debian too, and we
> spoke about this some time ago.
>
> 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. glibc is
> the place that needs to care about most of this.
>
> 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!)
>
> * 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. When we had to do
> something like this in the past, to deal with the libc5->libc6
> transition, we had an SONAME change in libc to work with. We decided
> to append the "g" tag to the names of our library binary packages to
> signal that a library was built against libc6. We can still see some
> of the effects of this in the archive, many years later
> (e.g. zlib1g). The problem now is that we will *not* have an soname
> change here to help identify code compatibility on the 32-bit front.
>
> Arnd scanned the library packages in the Debian archive and identified
> that about one third of our library packages would need rebuilding
> (and tracking) to make a (recursive) transition. We can see two
> different possible routes to follow:
>
> A Follow a similar path to last time (rename library packages). This
> will allow us to do partial upgrades, but the cost is that a vast
> number of packages will need work to make this happen,
> *potentially* building library packages twice to allow us to
> continue both 32-bit and 64-bit time_t support forwards for a
> while. This effort will be *needed* only for the sake of our 32-bit
> ports, but would affect *everybody*.
>
> *** OR ***
>
> 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.
>
> So, which way should we go? My own personal gut feel matches Arnd's,
> which would be route B. Some of us already have fair experience with
> bootstrapping new arches, and we could almost just crank the handle
> for most of this work.
>
Is there the option C?
Draft:
1. define time64_t
2. for data_struct which act as a part of ABI, define a new data_struct64
3. for function which act as part of ABI, define a new version func64.
4. patch all packages to use time64_t instead of time_t step by step.
5. set a time as deadline (2030?), and then treat all packages
haven't finished
the migration as rc-buggy.
Since we have enough time, we can patch all packages in that period.
> What do people think here? Which do you think is the better path? Feel
> free to point out things you think I may have missed. We should get
> started on this soon - the longer we leave it, the more likely it is
> that we'll see 2038 bugs biting people.
>
> --
> Steve McIntyre, Cambridge, UK. steve@einval.com
> "Yes, of course duct tape works in a near-vacuum. Duct tape works
> anywhere. Duct tape is magic and should be worshipped."
> -― Andy Weir, "The Martian"
>
--
YunQiang Su
Reply to: