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

[Zhaoming Luo]

On 1/1/25 5:50 PM, Sergey Bugaev wrote:
> Happy New Year!
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.
What's the best way to handle the MIG_BAD_ID case. I tried perror(NULL) 
but it gave my output '(ipc/mig) bad request message ID'. To be honest I 
don't think it's a very useful output. Is there a better option?
> 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.
OK. I will do the following:
```
__set_errno(err);
return -1;
```

--
Zhaoming Luo