Mark Kettenis <mark.kette...@xs4all.nl> wrote: > [...] And you also need to find a > solution for proper synchronization between userland and the kernel. > Currently they can race eachother in the sense that userland can read > the time at the same time the kernel is updating it. A generation > mechanism like the timehands use may be appropriate. You can't use locks!
Absolutely. This design is totally broken. You cannot just structure copy. Consider seperately what happens when big-endian and little-endian systems copy the two integers in this structures. In both cases, userland can read a region of bytes which is partially the old time, and partially the future. The read value is garbage. It is a false value in the future or the time. Monotonicity is out the window. > Also, I think we need a versioning mechanism for the shared page, such > that libc can verify that it understands the interface offered by the > kernel. Maybe a major/minor number at the start of the page. If the > version check fails we can fall back on the system call. That allows > updates without a flag day. Yep. > If you really don't want to implement the TSC approach now, we could > consider introducing CLOCK_MONOTONIC_COARSE and CLOCK_REALTIME_COARSE > and use your implementation just for those two. Which likely doesn't improve any of the applications being targeted.
