Using this combination of arguments currently crashes. This set of patches supports the port of openntpd to GNU/Hurd. The openntpd code specifies an adjustment to the system time once it has determined an initial deviation from true time. At some point later it checks the remaining time adjustment in the kernel to see how it differs from what was expected.
__adjtime (const struct timeval *delta, struct timeval *olddelta) openntpd calls adjtime with delta as NULL and a non-NULL olddelta. GNU/Hurd does not support this combination currently. 1) Changes to gnumach: 1a) Addition of a constant MACH_ADJTIME_SECS_MAX. This value is close to the largest number of seconds that can be managed with host_adjust_time64(). (2145 is (was?) supported on Linux so I specified that rather than a theoretical 2146). 1b) Alteration to host_adjust_time64() to disregard the new delta when it is outside the permitted range but still return KERN_SUCCESS so that the old delta can be retrieved. 2) Change to glibc __adjtime: 2a) The current code casts 'struct timeval' to 'struct time_value' claiming that they are identical. They possibly were in 32 bit but are not in 64 bit since the microseconds type differs between int and long int. When the microseconds value is negative the representation of the two type values differ and an incorrect value results to callers. 2b) Use MACH_ADJTIME_SECS_MAX so that callers can pass NULL for the new delta. This allows the existing time adjustment to be determined. Changes from v1: *) I've made the dependency on the gnumach optional using Amos' suggestion. *) I've reverted to using _MAX rather than _LIMIT as 2145 is well within the range of 'int' making it clear that _MAX + 1 is valid. I've tested the above with openntpd and my own test code. I'm still uncertain whether an error should be returned when delta 'seconds' limit is breached (but still populate old_delta). Regards, Mike.
