This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [RFC v2 08/20] sysdeps/wait: Use waitid if avaliable
* 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