On 15/12/2021 13:06:30-0800, John Stultz wrote: > I'm not really active in this space much anymore, but a few of my > (possibly wrongheaded) thoughts: > > > [A] On machines with a persistent clock how is userspace supposed > > to be sure what drift to measure? Can it assume that the drift > > of the persistent clock used for sleep time injection is the > > same as the drift of /dev/rtc? This seems dangerous. > > Yea, there can be multiple RTCs as well. > > > [B] Sleep time injection can come from the "persistent clock" or, > > if there is no persistent clock, from an RTC driver. I'd like > > to correct for drift from the perisistant clock but not touch > > the RTC driver sleep time injection mechanism. Is this > > acceptable or do people feel that any drift correction should > > work with both mechanisms in order to ensure a polished > > interface? > > This dual interface comes from the desire to support both the more > atomic/earlier correction we can do w/ the persistent_clock interface > while holding the timekeeping lock, while also supporting RTC devices > that may sleep when being read, or may have dependencies that aren't > ready that early in resume. > > Admittedly having two separate abstractions here is a bit of a pain, > and fixing just one side doesn't make it better. > > > [C] Some users may want to correct for drift during suspend-to-RAM > > but during suspend-to-disk they might boot into some other > > operating system which itself sets the CMOS RTC. Hopefully, > > this could be solved from userspace by changing the drift > > correction parameter to 0 just before a suspend-to-disk > > operation. > > Oof. This feels particularly complex and fragile to try to address. > > > I suspect that there are other things about which I should also be > > worried if only I were less ignorant. That is why I am asking here. > > Personally, I'm not sure this warrants adding new userland interfaces > for. I'd probably lean towards having the RTC framework internally > measure and correct for drift, rather than adding an extra knob in > userland. > I'd rather lean towards the timekeeping code doing that. The RTC subsystem doesn't know which RTC has to be used. -- Alexandre Belloni, co-owner and COO, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
