Re: [RFC PATCH glic] hurd: Add CLOCK_MONOTONIC case in clock_gettime()

[Sergey Bugaev]

Happy New Year!

On Wed, Jan 1, 2025 at 12:25 PM Zhaoming Luo <zhmingluo@163.com> wrote:
>
> ---
>  sysdeps/mach/clock_gettime.c | 12 ++++++++++++
>  1 file changed, 12 insertions(+)
>
> diff --git a/sysdeps/mach/clock_gettime.c b/sysdeps/mach/clock_gettime.c
> index 6fffad39f5..22faf85730 100644
> --- a/sysdeps/mach/clock_gettime.c
> +++ b/sysdeps/mach/clock_gettime.c
> @@ -31,6 +31,18 @@ __clock_gettime (clockid_t clock_id, struct timespec *ts)
>
>    switch (clock_id) {
>
> +    case CLOCK_MONOTONIC:
> +      {
> +       /* __host_get_uptime64 can only fail if passed an invalid host_t.
> +          __mach_host_self could theoretically fail (producing an
> +          invalid host_t) due to resource exhaustion, but we assume
> +          this will never happen.  */
> +       time_value64_t tv;
> +       __host_get_uptime64 (__mach_host_self (), &tv);

mach_host_self () cannot really fail, it just always returns 2 (the
cached result of the underlying mach_host_self Mach trap, see
glibc:mach/mach_init.c). So indeed no need to consider that case.

host_get_uptime64 was just added (by you) to gnumach, right? So what
can quite likely happen is:

- it's not present in the version of Mach that glibc is being built against
- it's not present in the version of Mach that glibc is being run on

in the latter case, you should get MIG_BAD_ID from the kernel, so you
can detect that.

It's also a good idea to handle RPCs failing for misc reasons, so
please don't just ignore the return code. If there's nothing better to
do with it, assert_perror (err) will abort with the error message, but
maybe in this case it would make more sense to propagate the failure
to the caller, even if it's not supposed to happen.

Sergey