This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [RFC v1 01/16] sysdeps/nanosleep: Use clock_nanosleep_time64 instead of nanosleep
On Sun, Jun 23, 2019 at 9:48 AM Florian Weimer <fweimer@redhat.com> wrote:
>
> * Alistair Francis:
>
> > On Sat, Jun 22, 2019 at 11:34 PM Florian Weimer <fweimer@redhat.com> wrote:
> >>
> >> * Alistair Francis:
> >>
> >> > +2019-06-21 Alistair Francis <alistair.francis@wdc.com>
> >> > +
> >> > + * nptl/thrd_sleep.c: Use clock_nanosleep_time64 instead of nanosleep.
> >> > + * sysdeps/unix/sysv/linux/nanosleep.c: Likewise.
> >> > + * sysdeps/unix/sysv/linux/nanosleep_nocancel.c: Likewise.
> >>
> >> Sorry, how is this supposed to work for all the other architectures
> >> which don't have this system call with current kernel versions?
> >
> > Good question, I'm sure it doesn't.
> >
> > If we put this around #if defined(clock_nanosleep_time64) or #ifndef
> > clock_nanosleep and then keep the current code as the #else would that
> > be acceptable to upstream?
>
> Does this work in <sysdep.h> for the port?
>
> #define __NR_clock_nanosleep __NR_clock_nanosleep_time64
I'm at home today so I can't check, but I suspect that will work.
>
> This is somewhat hackish, but it's reasonably accurate for architectures
> that provide standard system calls under non-standard names for some
> reason.
For the RV32 case I think this will provide a workable solution. I am
under the impression though that all 32-bit architectures are
eventually removing __ARCH_WANT_TIME32_SYSCALLS from Linux so they
will also hit this issue. Which is why I was going for a more generic
approach. In saying that, whatever gets the RV32 port in works for me
:)
>
> Obviously, this assume that for these new ports, the UAPI headers do the
> right thing and use 64-bit time_t for the old structs as well.
AFAIK they should be, at least in this case.
Alistair
>
> Thanks,
> Florian