[PATCH 6/6] cputime: Introduce cputime_to_timespec64()/timespec64_to_cputime()
baolin.wang at linaro.org
Thu Jul 16 12:22:43 AEST 2015
On 15 July 2015 at 19:55, Thomas Gleixner <tglx at linutronix.de> wrote:
> On Wed, 15 Jul 2015, Baolin Wang wrote:
>> On 15 July 2015 at 18:31, Thomas Gleixner <tglx at linutronix.de> wrote:
>> > On Wed, 15 Jul 2015, Baolin Wang wrote:
>> >> 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
> 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 can see that conversion in patch "posix-cpu-timers: Convert to
>> y2038 safe callbacks" from
> I do not care about your random git tree. I care about proper
> changelogs. Your changelogs are just a copied boilerplate full of
More information about the Linuxppc-dev