Hi Tina,
On 25/05/15 07:07, Tina Ruchandani wrote:
> 'struct timeval' uses a 32-bit representation for the
> seconds field which will overflow in the year 2038 and beyond.
> This patch replaces the usage of 'struct timeval' with
> ktime_t which uses a 64-bit time representation and does not
> suff
On Friday 05 June 2015 00:55:05 Tina Ruchandani wrote:
> >>> + hz = 100/delta;
> >
> > This needs to be on of the do_div family.
> >
> > Dave.
>
> Hi Dave,
> I build-tested the patch for both 32-bit and 64-bit x86. If my
> understanding is correct, since the divisor is 64-bit here, the
> c
>>> + hz = 100/delta;
>
> This needs to be on of the do_div family.
>
> Dave.
Hi Dave,
I build-tested the patch for both 32-bit and 64-bit x86. If my
understanding is correct, since the divisor is 64-bit here, the
compiler will do "if (delta > 100) hz = 0; else hz =
100/(s32)delta"
On 3 June 2015 at 21:59, Tomi Valkeinen wrote:
>
>
> On 25/05/15 07:07, Tina Ruchandani wrote:
>> 'struct timeval' uses a 32-bit representation for the
>> seconds field which will overflow in the year 2038 and beyond.
>> This patch replaces the usage of 'struct timeval' with
>> ktime_t which uses
On 25/05/15 07:07, Tina Ruchandani wrote:
> 'struct timeval' uses a 32-bit representation for the
> seconds field which will overflow in the year 2038 and beyond.
> This patch replaces the usage of 'struct timeval' with
> ktime_t which uses a 64-bit time representation and does not
> suffer from
'struct timeval' uses a 32-bit representation for the
seconds field which will overflow in the year 2038 and beyond.
This patch replaces the usage of 'struct timeval' with
ktime_t which uses a 64-bit time representation and does not
suffer from the y2038 problem. This patch is part of a larger
effo
6 matches
Mail list logo
