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

[Florian Weimer <fweimer at redhat dot com>]

* Arnd Bergmann:

> On Tue, Jun 25, 2019 at 4:08 PM Florian Weimer <fweimer@redhat.com> wrote:
>> * Arnd Bergmann:
>> > On Tue, Jun 25, 2019 at 3:47 PM Florian Weimer <fweimer@redhat.com> wrote:
>> >> This makes me rather unhappy.  I also don't see the benefit of renaming
>> >> all time-related system calls for new architectures.
>> >
>> > What got renamed?
>>
>> futex to futex_time64 on RV32.  <asm/unistd.h> seems to expose only the
>> latter.
>
> But that's the point: futex() takes a timespec argument based on 'long',
> so that won't work beyond y2038 on 32-bit architectures and we
> cannot provide that.
>
> One of the highest priorities in the conversion was always to ensure
> that new architectures would behave exactly the same way as the
> existing ones, except for leaving out the compatibility support for
> old C libraries that never existed on those architectures.
>
> Reusing the old __NR_futex() macro with a new ABI would require
> having architecture specific hacks even in C libraries that never
> supported 32-bit time_t on any architectures, or that dropped that
> support.

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.

Thanks,
Florian