An idea and proposal about system time

[Thomas Schwinge]

Hello!

This is for one an attempt to solve <http://savannah.gnu.org/task/?5492>
``gnumach should be able to handle local time in RTC'' in an elegant way,
but -- while actually achieving that -- also quickly goes one sphere
further.  It's about system time.


There are currently two possible ways to get to know the kernel's idea
(and therefore currently also the system's idea) of the system time: for
one there's (a) glibc's `gettimeofday' interface which in turn maps (save
timezones, which are not implemented) one-to-one to Mach's
`host_get_time' interface and (b) there is `libshouldbeinlibc''s
`maptime' interface.

(a) just does what one would expect it to do: ask the kernel and return
that.  (b) is different.  Mach maintains a region of memory where its
idea of the current time is stored and that region can be mapped into the
user's address space and can be safely read with `libshouldbeinlibc''s
`maptime_read'.  Compared to (a) this is more efficient, as no kernel
call is needed.  (a) in fact does exactly what (b) does, only that it's
done in kernel space compared to user space, to provide the
`host_get_time' interface.


Now, how does Mach get to know the current time, after all?  Essentially,
it has a variable to store the current time, which is initialized at
boot-up from the hardware's real time clock and then maintained with each
clock tick in a way that every second of wall time (mostly) corresponds
to an enhancement of one second of that variable.


We could do the following: remove from Mach its idea of an absolute time
and have it just provide a relative time, starting from zero at every new
system boot-up.  That is, make it a source of (more or less) regular
ticks.  As far as I can tell, Mach has no need to know (and even no
benefit from knowing) the world's wall time.


Converting that new relative time to an absolute system time would then
be realized by a (to-be-written) `/hurd/time' translator, which would be
initialized -- as Mach's time previously was -- by a pc's real time clock
(be it running in gmt or local time) or whatever and would then also
implement frequency adjustments, based on ntp data, for example.

For the frequency adjustment issue there are two approaches possible:
either we directly incorporate code of an ntpd or we provide an `adjtime'
like interface and have glibc's `adjtime' function use that on a system
default `/hurd/time' translator, residing on `/servers/time', for
example.  The same would be done for `gettimeofday' and `settimeofday'.
Additionally there may be provided inside glibc the possibility for a
user to override the system's default time translator and instead use the
one specified in the environment variable `TIMESERVER', akin to
`CRASHSERVER' and (in theory) `EXECSERVERS'.


Chaining of time translators would be possible.  (But I yet have to come
up with a useful usage scenario for that.)


So, what does this actually buy us?  For one, the aforementioned issue
about currently not being about to handle real time clocks that are
running in local time is resolved.  Then, we move functionality out of
the kernel that need not be there.


An open issue to me so far is if we can find an efficient way to continue
providing `libshouldbeinlibc''s `maptime' interface.


Comments?


Regards,
 Thomas

signature.asc
Description: Digital signature