> From: "Todd C. Miller" <todd.mil...@sudo.ws> > Date: Fri, 19 Jun 2020 12:24:33 -0600 > > On Fri, 19 Jun 2020 18:52:40 +0200, Mark Kettenis wrote: > > > There is one other issue that I wanted to raise. An that is whether > > we really need to implement CLOCK_UPTINME as a userland clock. If we > > don't do that we can drop tk_naptime from the shared struct. I > > mention this because th_naptime was only recently added to struct > > timehands and much more an implementation detail than the other fields. > > > > I don't expect userland processes to call CLOCK_UPTIME in a loop like > > they tend to do do for CLOCK_MONOTONIC and CLOCK_REALTIME. Linux > > doesn't have it ;). > > That's not entirely true. On Linux, CLOCK_MONOTONIC does not count > time that the system is suspended so it is analogous to our > CLOCK_UPTIME. On Linux CLOCK_BOOTTIME is the clock that counts > time while suspended. On OpenBSD CLOCK_BOOTTIME and CLOCK_MONOTONIC > are the same but that is not true of other systems.
Sure, Linux doesn't faithfully implement POSIX in this respect. But most software doesn't actually care about the difference and Linux does not have CLOCK_UPTIME which was my point. Anyway, if the consensus is that we should offer CLOCK_UPTIME that's fine with me. It just means that we have to be a bit more careful tinkering with the timecounter internals in the future. We can always get out of this hole we're digging by disabling the userland optimization. Yes, folks have to realize that is an optimization, and an optimization that you can't rely on. It won't be available on all machines. And it may not be available when you're doing an upgrade of some sort.
