Re: [PATCH 7/9] RFC: rtc: implement rtc_read_timeval()

From: John Stultz
Date: Fri Jun 14 2013 - 15:18:32 EST

On 06/14/2013 10:43 AM, Alexander Holler wrote:
Am 14.06.2013 19:23, schrieb John Stultz:
On 06/14/2013 09:52 AM, Alexander Holler wrote:
Some RTCs offer a higher resolution than seconds. To support reading such
high resolution timestamps from inside the kernel implement
rtc_read_timeval() and add a read_timeval to the rtc-ops.

So I like the direction this patch is going. But if we're going to add a
new interface, lets not use an already out-dated structure (timeval).

Instead could you rework this to be timepsec based? Or ktime_t if its
really internal only?

Sure, no problem. I wasn't aware timeval is out-dated and I've read somewhere in the sources a comment that ktime_t has to disappear. I had no clue if I should use timeval or timespec, and just have roled a dice to decide between timeval and timespec.

That "internal only" is only because I don't want to write changes for the userspace api to handle RTCs with greater precision than seconds. I don't have a writable RTC supporting such a precision and I want to leave this for people which are developing such devices and earning money with them.

Ok. Pushing it out to userland and the settime interfaces are probably logically separate enough.

That said, the the pain with this change is it leaves us with duplicate internal interfaces to read the time. So at some point we'll have to go through all the clocksource drivers and convert them to provide the timespec granular method, even if they just return the second portion.

Otherwise, you end up with a mishmash of some users using the second granular and some users using the highres and not all RTCs working for all users (or the users have to do their own fallback logic).

That said, I think such a transition is needed eventually, and this gets us at least started in that direction.

Alessandro: You have any thoughts here on how to best approach this sort of eventually far-reaching change?


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at