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
_______________________________________________ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
