On 10/04/2026 08:20, Mike Kelly wrote:
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. Hurd does not support this combination currently.
1) Changes to gnumach:
1a) Addition of a constant MACH_ADJTIME_SECS_INVALID. This value is
close to the highest possible value that can be represented in micro
seconds in the signed 64 bit data type. It is a preposterously large
number and such a time adjustment would surely never be performed
incrementally.
I couldn't use -1 for MACH_ADJTIME_SECS_INVALID because it is
acceptable to specify both positive and negative time adjustments.
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.
Why not '0' for "no change" ?
I have not checked, but that should be safe to send to old Mach without
risking corrupting the clock.
2) Change to glibc:
Make use of the above as required.
I've tested the above with openntpd and my own test code. Although it
works I'm unhappy with it for various reasons:
*) Is it necessary to connect the dependencies introduced with these
changes ? ie. libc0.3 version-xxx requires gnumach version-yyy.
Better make the glibc depend on existence of the new
MACH_ADJTIME_SECS_INVALID macro to enable support at built-time.
*) I'm not happy with the name of the 'MACH_ADJTIME_SECS_INVALID'. I
wanted something that could be used directly rather than having to
write for example MACH_ADJTIME_SECS_MAX + 1.
Perhapse "_CHECK" instead of "_INVALID" ?
*) The value of MACH_ADJTIME_SECS_INVALID is ridiculosuly large but is
almost identical to the maximum value that can currently be
specified.
*) Should there be an error other than KERN_SUCCESS that indicates an
invalid newdelta but a valid olddelta rather than just disregarding
newdelta under these circumstances?
Regards,
Mike.
/2c
AYJ