linux-kernel - Re: clock_getres() and real resolution

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: <alpine.LFD.2.02.1202091051310.2794@ionos>
Date:	Thu, 9 Feb 2012 11:12:48 +0100 (CET)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Dmitry Antipov <dmitry.antipov@...aro.org>
cc:	John Stultz <john.stultz@...aro.org>, linux-kernel@...r.kernel.org,
	linaro-dev@...ts.linaro.org
Subject: Re: clock_getres() and real resolution

On Wed, 8 Feb 2012, Dmitry Antipov wrote:

> IIUC, an idea behind clock_getres() is to give a hint about the resolution of
> specified clock. This hint may be used by an application programmer to check
> whether
> this clock is suitable for a some purpose. So why clock_getres() always
> returns
> something like {0, 1} (if hrtimers are enabled) regardless of the underlying
> platform's
> real numbers?
> 
> For example, OMAP4's real resolution of CLOCK_REALTIME is 30.5us for 32K timer
> and 26ns
> for MPU timer. Such a difference definitely makes sense - but
> clock_getres(CLOCK_REALTIME,..)
> always returns {0, KTIME_HIGH_RES}. Since this behavior causes a confusion
> like
> http://lists.linaro.org/pipermail/linaro-dev/2012-February/010112.html, I'm
> considering
> this as a stupid misfeature.

We had this discussion before. The point is that the accuracy of the
internal kernel timer handling is 1nsec in case of high resolution
timers. The fact that the underlying clock event device has a coarser
resolution does not change that. 

It would be possible to return the real resolution of the clock event
device, but we have systems, where the clockevent device is
dynamically changing. So which resolution do we expose to an
application? The one of the current active device or some magic number
of a device which might not even be initialized? That's more confusing
than telling user space that high resolution timers are active and the
kernel is trying to achieve the 1ns accuracy.

Thanks,

	tglx
--
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/