summaryrefslogtreecommitdiff
path: root/open_issues/clock_gettime.mdwn
diff options
context:
space:
mode:
authorThomas Schwinge <tschwinge@gnu.org>2011-09-01 09:27:33 +0200
committerThomas Schwinge <tschwinge@gnu.org>2011-09-01 09:27:33 +0200
commit3e7472b3d54853389cd8a17475901fbef976ef18 (patch)
treefdd31020d36728fe3c2059fa93a9dfcf7b2c2e87 /open_issues/clock_gettime.mdwn
parent688fc9d79713c183c0b7ff2bc1717525c773bee9 (diff)
IRC.
Diffstat (limited to 'open_issues/clock_gettime.mdwn')
-rw-r--r--open_issues/clock_gettime.mdwn28
1 files changed, 25 insertions, 3 deletions
diff --git a/open_issues/clock_gettime.mdwn b/open_issues/clock_gettime.mdwn
index bba0d171..c06edc9b 100644
--- a/open_issues/clock_gettime.mdwn
+++ b/open_issues/clock_gettime.mdwn
@@ -12,8 +12,30 @@ License|/fdl]]."]]"""]]
[[!tag open_issue_glibc open_issue_gnumach]]
-Missing clock_gettime(CLOCK_MONOTONIC) (e.g. for iceweasel)
+Missing `clock_gettime(CLOCK_MONOTONIC)` (e.g. for iceweasel)
-It could be a mere matter of extending the mappable clock: add it to mapped_time_value_t in gnumach, handle it in gnumach/kern/mach_clock.c, and make clock_gettime use it.
+It could be a mere matter of extending the mappable clock: add it to
+`mapped_time_value_t` in gnumach, handle it in `gnumach/kern/mach_clock.c`, and
+make `clock_gettime` use it.
-BTW, also make gettimeofday() use it, since it's way more efficient and some applications assume that it is.
+BTW, also make `gettimeofday()` use it, since it's way more efficient and some
+applications assume that it is.
+
+What about adding a nanosecond-precision clock, too? --[[tschwinge]]
+
+IRC, freenode, #hurd, 2011-08-26:
+
+ < pinotree> youpi: thing is: apparently i found a simple way to have a
+ monotonic clock as mmap-able device inside gnumach
+ < pinotree> currently, in kern/mach_clock.c there's a variable 'time',
+ which gets increased on clock interrupt, and optionally modified by
+ host_set_time
+ < pinotree> ()
+ < pinotree> if i add a new variable next to it, only increasing it on
+ interrupt but not modifying it at all otherwise, would that give me a
+ monotonic clock?
+ < pinotree> at least on sme basic tests i did, it seems it could work that
+ way
+ < youpi> yes, it should work
+ < braunr> sure
+ < youpi> and that's the way I was considering implementing it