Theo de Raadt: > > Then you still need to check on every call whether the clockid has > > changed (because the kern.timecounter.hardware sysctl was changed) > > and refetch the function pointer in that case. > > Then really, we should remove that sysctl support. > > Because otherwise I don't see how it can work. Aren't there deadlock > or spinning conditions? Or at minimum, situtions where time won't flow > linearly.
The patch as-is works fine when kern.timecounter.hardware is toggled back and forth between tsc with userland gettime support and, say, acpihpet0 without. tk_user marks whether the currently selected timecounter has userland support, the wrapper checks that and falls back to the system call. Reading the code, I don't see a reason why this shouldn't work fine, and experimentally it does work. Changing kern.timecounter.hardware is transparent. kettenis@'s suggestion of extending this from on/off to clockid1/clockid2/.../off makes sense to me. Most architectures will likely only have one timecounter for which userland support is possible, but sparc64 has indeed two (tick, stick). -- Christian "naddy" Weisgerber na...@mips.inka.de
