On 15/12/2021 15:26:28-0800, John Stultz wrote: > > Any method of measuring the drift is going to need to persist the > > drift coefficient to disk so that it can set the system clock > > correctly on boot. I think it would be best for the kernel to use this > > same coefficient. > > My initial thought was for the rtc class layer to do the estimation > internally against the system time (assuming it was NTP corrected) to > try establish a close enough correction factor as the system was up > and running, but you're right that would be reset on every reboot, and > with second granular RTCs accurate error calculations will take awhile > (though polling for the second-edge might work well enough, but would > be cpu heavy for a background task). > > Maybe that's a good enough argument for having an ADJ ioctl added to > the rtc chardev? > Then why not got for the correction software emulation? that would avoid duplicating interfaces and we'd avoid to use it on RTCs with hardware support. > But it also seems to suggest that if chronyd already has all this > logic in userland, maybe having it calculate and call settimeofday() > on resume from userland instead of pushing half of that logic into the > kernel? My suggestion would leave the correction calculation to userspace which is definitively where it should stay. > > > > Alternatively I'd go very simple and just put the correction factor in > > > a boot argument. > > > > This works for my use case though it won't be useful to a general > > distro. Would you have one argument being used regardless of where the > > sleep injection was coming from or would you try to tie it to the > > persistent clock and/or a specific RTC? > > I agree it is an important thing to consider how to generalize this > for common use (which is why I prefer the approach that works > *without* any distro integration). > > But it's also important to consider if the added complexity is > *really* needed in the general case. > > thanks > -john -- Alexandre Belloni, co-owner and COO, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
