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

[Florian Weimer <fweimer at redhat dot com>]

* Arnd Bergmann:

>> If not, there is no risk at all that programmers confuse the types, and
>> no need to rename the systen calls.
>>
>> If there's only a 64-bit time_t, calling futex futex_time64 makes as
>> much sense as alpha calling getpid getxpid.
>
> No, the rule for syscalls in the kernel is to give a new name if you
> change the arguments. When we went through multiple revisions for
> fadvise/fadvise64/fadvise64_64, we could have made it so that
> each new architecture only has the latest version by the name of
> 'fadvise', but I think that would have been really confusing.

But futex is different because in userspace, futex_time64 behaves
exactly like futex on other architectures on rv32.

> I also really don't want to have a different definition of timespec
> in the kernel for rv32 and get people to use that. Instead I think
> anyone using the __NR_* macros should really use __kernel_timespec
> and other __kernel_* types from the kernel headers in place of
> the libc types in the long run. Properly cleaning up the kernel
> headers is something we definitely need to do at some point
> but have no specific plan for.

There's only __kernel_old_timeval, no __kernel_old_timespec, so you
can't use the kernel headers to write the 32-bit fallback path.  Once we
get _TIME_BITS=64 (to change struct timespec to 64-bit, like
_FILE_OFFSET_BITS), you can't use the glibc header files either.  Not
good.

>> > The version above will
>> > - always use __NR_futex on 64-bit architectures and x32
>> > - use __NR_futex on 32-bit architectures with 32-bit time_t, this will always
>> >   work except on kernels that don't support time32 syscalls (as intended)
>> > - use __NR_futex_time64 on 32-bit architectures with 64-bit time_t, which
>> >   works when built with linux-5.1+ headers and running on linux-5.1+.
>> >   This is probably good enough, as many other things are also broken
>> >   when trying to use time64 with older kernels or headers.
>>
>> I think the quoted fix isn't the best we can do.  Portable binaries
>> 32-bit binaries need to call futex_time64 once to see if it is
>> available, and fall back to futex if it is not.  g_cond_wait_until in
>> particular does not have a dependency on the size of struct timespec,
>> but other parts of glib might, and it may not be possible to compile
>> glib as a while with __TIMESIZE == 64.
>
> Can you clarify this? Making glib work with __TIMESIZE == 64 is
> clearly required anyway,

I'm not sure.  glib could deprecate all the APIs that use time_t
externally.  Given that they don't want to bump ABI, they may not want
to compile with __TIMESIZE == 64 on old 32-bit systems.

> and g_cond_wait_until() cannot work unless the local timeout structure
> has the same type that the kernel expects.

True, and that code is currently really, really hard to write (for
legacy 32-bit architectures).  For new 32-bit architectures, there is
just pointless source code difference without any added value in terms
of type safety.

>> But t his is really an aside.  I'm concerned that porting software to
>> rv32 requires that applications have to deal with the time_t transition
>> today, and I don't see a good reason for linking the two.
>
> The risc-v kernel maintainers specifically wanted to wait for the
> time_t transition with libc, in order for rv32 to avoid going through
> the transition after binaries are widely distributed already.

That's a different concern.  They didn't want a 32-bit-time_t ABI.  I
expect that they might have chosen differently if they realized that
they'd need to absorb the userspace 64-bit porting cost, just to get
rv32 going.

> As I said before, we could easily undo the one-line change in the
> kernel and start out with the usual 32-bit off_t/time_t/... in glibc
> if it turns out to be too hard to get this to work.

glibc isn't the problem.  It's source-level changes to applications
which use kernel headers.

Thanks,
Florian