On 2018-02-19 11:07, Alexandre Belloni wrote: > On 19/02/2018 at 12:16:04 +0300, Igor Plyatov wrote: >> Dear Rasmus, >> >> thank you very much for explanation! >> >> I have set "RTC_SET_DELAY_SECS = 0.0" in hwclock.c and got acceptable >> result. >> >> It wonder why such critical function does not implemented on kernel level in >> RTC driver? >> It is very strange to rely on specific HW in user space SW. >> > > Because of the way the API is designed, handling the MC146818A oddity is > not possible in the driver (i.e. 50% of the time, it will be too late > to handle it). Well, I suppose one could implement an ioctl that would not actually take a struct rtctime from userspace but simply use the current value of clock_realtime (which is what 99% of rtc_set_times are using anyway), and doing it as accurately as possible (which requires implementations in each driver) - i.e., have the kernel do the appropriate sleeping which is currently done in userspace: a generic implementation of that ioctl would sleep until clock_realtime is a whole second, while the x86 driver could sleep until a .5 second. Sure, clock_realtime can jump or get adjusted while we sleep, and we can oversleep for all kinds of reasons, but the kernel is in a much better position to do the sleeping and knowing when to attempt the rtc setting than userspace. Said ioctl could also take an integer offset to apply to the clock_realtime value to support setting the rtc to some non-UTC timezone. > You can use busybox hwclock which has the x86 insanity commented out: > https://git.busybox.net/busybox/tree/util-linux/hwclock.c No, the code that is commented out is code that would actually try to do the rtc setting at a whole (system clock) second, which is what one wants on non-x86. It is apparently commented out because aiming for a whole second is not the right thing to do on some platforms (i.e., x86). So the current busybox code, on rtcs which set the fractional part to 0, end up discarding (losing) some uniformly distributed number from [0,1] instead of consistently .5 seconds. Also, AFAIR, the busybox code which implements the --hctosys doesn't do anything to do it right after the rtc has incremented, losing another [0, 1] uniformly. Rasmus -- To unsubscribe from this list: send the line "unsubscribe util-linux" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
