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


Reply via email to