lkml.org 
[lkml]   [2011]   [Dec]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [RFC 0/2] ABI for clock_gettime_ns
From
Date
On Wed, 2011-12-14 at 09:15 -0800, Andy Lutomirski wrote:
> On Wed, Dec 14, 2011 at 8:48 AM, john stultz <johnstul@us.ibm.com> wrote:
> > On Wed, 2011-12-14 at 08:46 +0100, Richard Cochran wrote:
> >>
> >> What about this sort of time value?
> >>
> >> struct sys_timeval {
> >> __s64 nanoseconds;
> >> __u32 fractional_ns;
> >> };
> >>
> >> The second field can just be zero, for now.
> >
> > I'm mixed on this.
> >
> > We could do this, as the kernel keeps track of sub-ns granularity.
> > However, its not stored in a decimal format. So I worry the extra math
> > needed to convert it to something usable might add extra overhead,
> > removing the gain of the proposed clock_gettime_ns() interface.
> >
>
> I would actually prefer units of 2^-32 ns over . I have no attachment
> to SI picoseconds so long as the units are constant.

2^-32ns would be much easier to do.


> Windows sidesteps this issue by returning arbitrary units and telling
> the user what those units are. This adds a lot of unpleasantness (try
> relating the timestamps to actual wall time) and we need to rescale
> the time anyway for NTP.
>
> What about:
>
> struct sys_timeval {
> u64 nanoseconds; /* unsigned. the current time will always be
> after 1970, and those extra 290 years might be nice. */

I'd suspect we will still need this to be signed if it goes to userland.
In-kernel u64 for nanoseconds is fine because it doesn't have to deal
with anything that far in the past. But for userland we probably should
use s64.

> u64 padding; /* for later. currently always zero. */
>
> That way, once there's both an implementation and a use case, we can
> implement it. In the mean time, the overhead is probably immeasurably
> low -- it's a single assignment.

This sounds good to me.

Kumar, Arun, I know we've strayed a bit from your original patch, but
any objections here?

thanks
-john






\
 
 \ /
  Last update: 2011-12-14 18:35    [W:0.129 / U:0.032 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site