chensong at tj.kylinos.cn
Tue Sep 15 09:05:16 CEST 2020
After going through Arnd Bergmann's patch
i'm going to get started at 64bit-xenomai y2038-safe(#1 in below list).
1, timespec to __kernel_timespec in syscalls
timespec to timespec64
2, timex to __kernel_timex
3, syscalls, probably make a new one for 64bits and keep the old one for
compatibility (like clock_gettime, nanosleep...)
4, 2038-unsafe points in scheduler if there is (like sched time
interval..., i found xntimer is 64bit, which means it's 2038-safe)
5, get_timespec to get_timespec64
timespec_valid to timespec64_valid
6, ktime_get_real to ktime_get_real_ts64
There would be more, i haven't figured out the whole pictures yet, and i
even haven't figured out how to make 32bit app 2038-safe either in 64bit
kernel or 32bit kernel, as far as my test, time goes back to 1901 when
sec is wrapped around in GPOS(5.4.40).
1) root at kylin-Lenovo:/home/kylin/workspace/test-2038# ./test2038-gcc-32bit
1, Local time is: Tue Jan 19 11:13:40 2038
2, Local time is: Tue Jan 19 11:13:50 2038
diff 10, sec 0x7fffffee
1, Local time is: Tue Jan 19 11:13:50 2038
2, Local time is: Tue Jan 19 11:14:00 2038
diff 10, sec 0x7ffffff8
1, Local time is: Tue Jan 19 11:14:00 2038
2, Local time is: Sat Dec 14 04:45:54 1901
diff 10, sec 0x80000002
But things are getting clearer, if you have no problem with that, i will
start some small patches for review.
Let me know your thought about it, many thanks.
On 2020/9/4 下午5:38, chensong via Xenomai wrote:
> hi Henning,
> I collected some discussions about y2038 from upstream and made a
> rough list for xenomai:
> 1, 64bit-xenomai y2038-safe
> 2, 32bit-xenomai y2038-safe
> 3, 64bit-ipipe y2038-safe (arm64, x86_64)
> 4, 32bit-ipipe y2038-safe (arm, x86)
> 5, syscall (posix and all other skins)
> 6, libc
> 7, 32 bit app y2038-safe
> 8, 64 bit app y2038-sage
> For #1 ~ #4 above , we take care of In-kernel correctness, all the
> data structures time is relevant to are going to be changed to long
> long.or any old time data structures used in either xenomai or
> ipipe(probably timespec to timespec64).
> For #5, we need to keep the old syscalls for compatibility and
> introduce new 64 bit syscalls.More specificlly, to create new 64bit
> time_t/timespec/timeval/etc variants for syscalls, while
> preserving existing interfaces(posix and all other skins).
> #6, do we need to care about it or we can benefit from upstream?
> #7, we need to cooperate with app developers and #8 seems to be safe
> other communities info :
> NetBSD preserved compatibility with 2038 unsafe applications
> OpenBSD did not (seeing the certainty of excluding unsafe
> applications as a feature over compatibility)
> I will continue to work on the test case and start figuring out 32bit
> time data structures in xenomai, how does it sound to you.
More information about the Xenomai