On 16 July 2015 at 18:43, Thomas Gleixner [off-list ref] wrote:

On Thu, 16 Jul 2015, Baolin Wang wrote:

quoted

On 15 July 2015 at 19:55, Thomas Gleixner [off-list ref] wrote:

quoted

On Wed, 15 Jul 2015, Baolin Wang wrote:

quoted

On 15 July 2015 at 18:31, Thomas Gleixner [off-list ref] wrote:

quoted

On Wed, 15 Jul 2015, Baolin Wang wrote:

quoted

The cputime_to_timespec() and timespec_to_cputime() functions are
not year 2038 safe on 32bit systems due to that the struct timepsec
will overflow in 2038 year.

And how is this relevant? cputime is not based on wall clock time at
all. So what has 2038 to do with cputime?

We want proper explanations WHY we need such a change.

When converting the posix-cpu-timers, it call the
cputime_to_timespec() function. Thus it need a conversion for this
function.

There is no requirement to convert posix-cpu-timers on their own. We
need to adopt the posix cpu timers code because it shares syscalls
with the other posix timers, but that still does not explain why we
need these functions.

In posix-cpu-timers, it also defined some 'k_clock struct' variables,
and we need to convert the callbacks of the 'k_clock struct' which are
not year 2038 safe on 32bit systems. Some callbacks which need to
convert call the cputime_to_timespec() function, thus we also want to
convert the cputime_to_timespec() function to a year 2038 safe
function to make all them ready for the year 2038 issue.

You are not getting it at all.

1) We need to change k_clock callbacks due to 2038 issues

2) posix cpu timers implement affected callbacks

3) posix cpu timers themself and cputime are NOT affected by 2038

So we have 2 options to change the code in posix cpu timers:

   A) Do the timespec/timespec64 conversion in the posix cpu timer
      callbacks and leave the cputime functions untouched.

   B) Implement cputime/timespec64 functions to avoid #A

   If you go for #B, you need to provide a reasonable explanation why
   it is better than #A. And that explanation has absolutely nothing
   to do with 2038 safety.

Very thanks for your explanation, and I'll think about that.

Not everything is a 2038 issue, just because the only tool you have is
a timespec64.

Thanks,

        tglx

-- 
Baolin.wang
Best Regards