On 01/21/2013 07:36 AM, Scot Salmon wrote:
One drawback of that solution for me is that for the specific clocks I
care about (MONO and REAL) it is not optimal. The delta between those two
clocks is available in the kernel timekeeping data, so a syscall just
handling those two would be able to get the exact offset quickly. I'd
still really like to be able to get that offset.
One way to do that would be to take a small step along the clock_gettime2
path and just have it return an error if the clockid's are anything other
than MONO and REAL. That seems ugly, but it's straightforward to
implement, and would work for me and maybe others with basically similar
requirements, so I'll throw it out there. Another option is to continue
all the way down the clock_gettime2 path, as John suggested:
Basically you need to split the current accsessor functions into two
parts:
1) The clocksource hardware read
2) The time calculation, given the clocksource value
Then for the gettime2() implementation, do a *single* read of the
hardware, and pass that clocksource value into the different specified
clockid functions.
Another important thing to consider here, is that if we are considering
adding a new syscall, we should avoid the 2038 issue, and specify a new
time64_t and timespec64 types, and use them in the new interface. This
way we can provide a 64bit time interface for 32bit systems.
This is something I'd like to work on, but it seems like a significant
project, and I'm wondering if it might be acceptable to start with the
reduced functionality version I mentioned above and work towards this.
Yea, its likely to be a reasonable amount of work to do it right
(although really, its not too crazy, given its pretty limited scope -
you're really just moving code into sub-functions). The problem with
starting with the reduced functionality, especially when there's a sense
of what the right approach should be, is that if we merge that,
*someone* still has to clean things up to really finish the interface.
So its usually not a good idea to merge such an approach unless there's
a clear commitment and history of the submitter following through.
The exceptions for this are usually when there's some interesting
feature, but no one knows how to best integrate it (ie: how deeply), and
in those cases, having a reduced functionality (even hackish)
implementation, lets folks get a better sense of the functionality and
what it duplicates or would integrate well with. In those cases, having
something merged to learn from is more valuable.
Now, as far as the 2038 issue goes, just defining the interface to be
64bit would be fine. You wouldn't have to convert all the internals to
64bits for just the interface to be useful (since converting the
internals to be 64bits is something on my todo already, and on 64bit
systems it would already be supported).
As a side note, Richard mentioned that the idea of a CLOCK_TAI has been
thrown around before. I agree with him that it would be a useful addition
for test & measurement applications.
Yea, I've had some CLOCK_TAI patches in my tree for awhile now. However,
its sort of half done, as I need to still integrate CLOCK_TAI hrtimer
support before it can properly be merged. I've not had the time recently
to finish this, but I'm hoping to get to it before too long (or so I've
said for the last few releases).
thanks
-john
--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
