linux-kernel - Re: [PATCH 7/9] RFC: rtc: implement rtc_read

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <51BB6C80.1070704@linaro.org>
Date:	Fri, 14 Jun 2013 12:18:24 -0700
From:	John Stultz <john.stultz@...aro.org>
To:	Alexander Holler <holler@...oftware.de>
CC:	linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	rtc-linux@...glegroups.com, Thomas Gleixner <tglx@...utronix.de>,
	Alessandro Zummo <a.zummo@...ertech.it>
Subject: Re: [PATCH 7/9] RFC: rtc: implement rtc_read_timeval()

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?

thanks
-john

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/