This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC v1 01/16] sysdeps/nanosleep: Use clock_nanosleep_time64 instead of nanosleep


On Sun, Jun 23, 2019 at 7:00 PM Alistair Francis <alistair23@gmail.com> wrote:
> 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
> :)

Generally speaking we never remove system calls from the kernel, rv32
was the exception to this rule because there was no upstream C library
port. __ARCH_WANT_TIME32_SYSCALLS will probably hang around for
shortly before year 2038 -- afterwards there is no point any more as all
binaries relying on it will be broken then.

We will however allow building kernels that omit the time32 syscalls
before then, as they are only adding baggage to the kernel size and
make it harder to verify that user space doesn't try calling them.

I think for internal libc functions, you need to try both functions:
first the time64 version for kernels that leave out the 32-bit one,
and then the time32 version for running on pre-5.1 kernels.

For user-visible glibc interfaces (e.g. nanosleep()), user space with
a 64-bit time_t will have to try the time64 syscall first and then fall
back on the time32 version for pre-5.1 kernels, while user space
with 32-bit time_t should only call the old time32 syscall and fail
on any kernel that doesn't support that, either because
__ARCH_WANT_TIME32_SYSCALLS is not set at compile
time, or because the kernel was configured without these.

     Arnd


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]