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 v2 06/20] sysdeps/futex: Use futex_time64 if avaliable


On Tue, Jun 25, 2019 at 2:07 PM Florian Weimer <fweimer@redhat.com> wrote:
> * Arnd Bergmann:
> > For instance pthread_timedjoin_np() is a public interface
> > that will need an additional version to deal with time64.
> > Should pthread_timedjoin_np() convert the user timespec
> > to __timespec64 and pass it down to lll_futex_syscall(),
> > which then converts it back to timespec before calling
> > __NR_futex() on 32-bit architectures, or is there a way to
> > avoid the double conversion?
>
> My expectation is that glibc will not provide a 32-bit struct timespec
> for architectures which do not have a 32-bit __NR_futex system call.
> It's a 64-bit only world.  Before the 2038 deadline, we will not support
> kernels that removed support for the 32-bit system calls.
>
> Based on that, I expect that the 32-bit struct timespec variant of
> pthread_timedjoin_np calls futex, and the 64-bit variant (probably named
> pthread_timedjoin64_np or something like that, or used by default under
> appropriate feature selection macros) will call futex_time64.  This has
> the advantage that the type of call is visible at the syscall layer, and
> could eventually trigger kenrel warnings.  With translation, that
> wouldn't be the case.  It also increases compatibility with seccomp
> filters which know of the old system calls, but not the new ones.

Ok, that's perfect as far as I'm concerned. From earlier discussions
I had understood that you were planning to avoid the associated
code duplication and only have one internal implementation for
the two external interfaces.

      Arnd


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