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