Re: [RFC v2 08/20] sysdeps/wait: Use waitid if avaliable

[Arnd Bergmann <arnd at arndb dot de>]

On Tue, Jun 25, 2019 at 4:29 PM Florian Weimer <fweimer@redhat.com> wrote:

>
> I think this fails to take into account that the type differences have
> clearly been abstracted away for struct timespec (you really need the
> definition from an official header), and perhaps even for time_t.
>
> If there is only a 64-bit version of those types, the syscall name
> difference does not add any value whatsoever.  In glibc, I think we will
> just add
>
> #define __NR_futex __NR_futex_time64
>
> for these architectures (only internally, we won't define SYS_futex).
> And any application that wants to call the futex system call directly
> will do the same thing.  Which leads to the question why the kernel
> headers aren't doing it.

I think it's a bad trade-off to do this hack for risc-v, and I don't
really want to encourage it.

Redefining __NR_futex for rv32 would clearly speed up the process
of the initial merge because it avoids the dependency on the general
ilp32-time64 support, but the cost would be to maintain rv32 as a
special case forever.

We already need three distinct variants of futex (and any other
time64 syscall):

a) 64-bit, timespec == __old_kernel_timespec == __kernel_timespec
futex() -> syscall(__NR_futex) -> sys_futex

b) 32-bit, timespec == __old_kernel_timespec; will stay around until ~2038
futex() -> syscall(__NR_futex) -> sys_futex

c) 32-bit, timespec == __kernel_timespec, being added now
futex() -> __futex_time64() -> syscall(__NR_futex_time64) -> sys_futex_time64

With __futex_time64() being an internal function like

int __futex_time64(...)
{
      int err = -ENOSYS;
#ifdef __NR_futex_time64
      err = syscall(__NR_futex_time64, ...);
#endif
#ifdef __NR_futex
      if (err = -ENOSYS) { /* pre-5.1 kernel */
            struct __kernel_old_timespec ts32 = ts64_to_ts32(ts);
            err = syscall(__NR_futex_time64, ... &ts32 ...);
      }
#endif
      return ret;
}

What I expected would happen here was to use the same as
case c) for rv32, while your approach would be closer to a),
with no intermediate function:

d) rv32, timespec == __kernel_timespec
futex() -> syscall(__NR_futex_time64) -> sys_futex_time64

This way you have to multiplex between time32 and time64 in
two places: existing architectures by calling __futex_time64()
instead of futex() (through whatever method you normally use
in glibc to choose between different ABI variants at link time),
while rv32 would use the old symbol but redefine the kernel
macros to do the same thing.

Is there any long-term advantage for your approach that I'm
missing?

      Arnd