On Tue, Nov 4, 2014 at 12:01 AM, Arnd Bergmann <arnd@xxxxxxxx> wrote: > On Monday 03 November 2014 17:11:53 John Stultz wrote: >> I've got some thoughts on what a possible interface that wouldn't be >> awful could look like, but I'm still hesitant because I don't really >> know if exposing this sort of data is actually a good idea long term. > > I was also thinking (while working on an unrelated patch) we could use > a system call like > > int clock_getoffset(clockid_t clkid, struct timespec *offs); > > that returns the current offset between CLOCK_REALTIME and the > requested timebase. It is of course racy, but so is every use > of CLOCK_REALTIME. We could also use a reference other than > CLOCK_REALTIME that might be more stable, but passing two arbitrary > clocks as input would make this much more complex to implement. Yea, this is too racy for me, at least for it to be useful. You get an offset, but you don't get any sense of what it was actually valid for. I think to be at all useful, you'll have to return both a timestamp for a given clockid, and an offset to the second clockid. That way you can generate a valid point in time on two clocks (as best as possible, given possible non-atomic reads of separately backed clockids). But again, I'm not totally sure exposing this provides that much value over userspace reading the two clocks itself (in ABA fashion) to sort this out. And I also don't see it as particularly related to this perf extension that Pawel is doing (since we are trying to avoid making the perf clock a directly accessible clockid). thanks -john -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
