Thomas Gleixner writes:
> That time value should be 64bit, also people might argue, that we are
> creating a new issue for the year 2554, i.e 541 years from now. I
> don't think we need to worry about that really. We have to leave our
> grand-grand-grand..grandchildren (~20 generations from now) a
Thomas Gleixner writes:
That time value should be 64bit, also people might argue, that we are
creating a new issue for the year 2554, i.e 541 years from now. I
don't think we need to worry about that really. We have to leave our
grand-grand-grand..grandchildren (~20 generations from now) a few
* Thomas Gleixner wrote:
> On Mon, 3 Jun 2013, John Stultz wrote:
> > On 06/03/2013 07:34 AM, Thomas Gleixner wrote:
> > > Though even if we fix that we still need to twist our brains around
> > > the timespec/timeval based user space interfaces. That's going to be
> > > the way more
* Thomas Gleixner t...@linutronix.de wrote:
On Mon, 3 Jun 2013, John Stultz wrote:
On 06/03/2013 07:34 AM, Thomas Gleixner wrote:
Though even if we fix that we still need to twist our brains around
the timespec/timeval based user space interfaces. That's going to be
the way more
On Mon, 3 Jun 2013, John Stultz wrote:
> On 06/03/2013 07:34 AM, Thomas Gleixner wrote:
> > Though even if we fix that we still need to twist our brains around
> > the timespec/timeval based user space interfaces. That's going to be
> > the way more interesting challenge.
>
> I'm curious if there
Tobias,
On Tue, 4 Jun 2013, Tobias Waldekranz wrote:
> On Mon, Jun 03, 2013 at 04:34:25PM +0200, Thomas Gleixner wrote:
> > Just "fixing" some random parts of the code in a "make it work
> > somehow" way is a pointless exercise IMO.
> >
> Now hold on, it is hardly random. On an ARM system, the
Tobias,
On Tue, 4 Jun 2013, Tobias Waldekranz wrote:
On Mon, Jun 03, 2013 at 04:34:25PM +0200, Thomas Gleixner wrote:
Just fixing some random parts of the code in a make it work
somehow way is a pointless exercise IMO.
Now hold on, it is hardly random. On an ARM system, the kernel will
On Mon, 3 Jun 2013, John Stultz wrote:
On 06/03/2013 07:34 AM, Thomas Gleixner wrote:
Though even if we fix that we still need to twist our brains around
the timespec/timeval based user space interfaces. That's going to be
the way more interesting challenge.
I'm curious if there are any
On Mon, Jun 03, 2013 at 04:34:25PM +0200, Thomas Gleixner wrote:
> B1;2601;0cOn Mon, 3 Jun 2013, Tobias Waldekranz wrote:
> > In ktime_get_update_offsets, calculate the current time in the same
> > way as in ktime_get.
> >
> > On 32-bit systems, the current time is truncated via the call to
> >
On Mon, Jun 03, 2013 at 04:34:25PM +0200, Thomas Gleixner wrote:
B1;2601;0cOn Mon, 3 Jun 2013, Tobias Waldekranz wrote:
In ktime_get_update_offsets, calculate the current time in the same
way as in ktime_get.
On 32-bit systems, the current time is truncated via the call to
ktime_set,
On 06/03/2013 07:34 AM, Thomas Gleixner wrote:
B1;2601;0cOn Mon, 3 Jun 2013, Tobias Waldekranz wrote:
In ktime_get_update_offsets, calculate the current time in the same
way as in ktime_get.
On 32-bit systems, the current time is truncated via the call to
ktime_set, the following subtraction
B1;2601;0cOn Mon, 3 Jun 2013, Tobias Waldekranz wrote:
> In ktime_get_update_offsets, calculate the current time in the same
> way as in ktime_get.
>
> On 32-bit systems, the current time is truncated via the call to
> ktime_set, the following subtraction of offs_real will result in an
>
In ktime_get_update_offsets, calculate the current time in the same
way as in ktime_get.
On 32-bit systems, the current time is truncated via the call to
ktime_set, the following subtraction of offs_real will result in an
inaccurate time when the current number of seconds since epoch can no
In ktime_get_update_offsets, calculate the current time in the same
way as in ktime_get.
On 32-bit systems, the current time is truncated via the call to
ktime_set, the following subtraction of offs_real will result in an
inaccurate time when the current number of seconds since epoch can no
B1;2601;0cOn Mon, 3 Jun 2013, Tobias Waldekranz wrote:
In ktime_get_update_offsets, calculate the current time in the same
way as in ktime_get.
On 32-bit systems, the current time is truncated via the call to
ktime_set, the following subtraction of offs_real will result in an
inaccurate
On 06/03/2013 07:34 AM, Thomas Gleixner wrote:
B1;2601;0cOn Mon, 3 Jun 2013, Tobias Waldekranz wrote:
In ktime_get_update_offsets, calculate the current time in the same
way as in ktime_get.
On 32-bit systems, the current time is truncated via the call to
ktime_set, the following subtraction
16 matches
Mail list logo
