This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [RFC v2 03/20] y2038: linux: Provide __clock_settime64 implementation
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Arnd Bergmann <arnd at arndb dot de>
- Cc: Lukasz Majewski <lukma at denx dot de>, Alistair Francis <alistair dot francis at wdc dot com>, GNU C Library <libc-alpha at sourceware dot org>, Adhemerval Zanella <adhemerval dot zanella at linaro dot org>, Florian Weimer <fweimer at redhat dot com>, Palmer Dabbelt <palmer at sifive dot com>, <macro at wdc dot com>, Zong Li <zongbox at gmail dot com>, Zong Li <zong at andestech dot com>, Alistair Francis <alistair23 at gmail dot com>
- Date: Mon, 8 Jul 2019 10:49:16 +0000
- Subject: Re: [RFC v2 03/20] y2038: linux: Provide __clock_settime64 implementation
- References: <cover.1561421042.git.alistair.francis@wdc.com> <4a1304510a5c9b5c2f6432bfdc5c9fd1740a081f.1561421042.git.alistair.francis@wdc.com> <CAK8P3a1fpqmFWMXAmV9KmuYFegRG958tLr9u=spELuRwXKfRiQ@mail.gmail.com> <20190625175125.03375ead@jawa> <CAK8P3a3AUgWzuZaZR5p2brmK16cMviidTf6A4aZ=mXVuNySbpA@mail.gmail.com>
On Tue, 25 Jun 2019, Arnd Bergmann wrote:
> Your __clock_settime however does the reverse: you have an application
> that calls clock_settime(), the alias redirects that to __clock_settime(),
> and that converts it into the 64-bit structure and passes it into
> __clock_settime64(), which then calls the time64 syscall before falling
> back to calling the time32 syscall.
Yes, that's exactly what it's meant to do.
My position is as stated at
<https://sourceware.org/ml/libc-alpha/2018-12/msg00136.html>. Duplicating
nontrivial functions at the source-code level for 32-bit / 64-bit time is
unmaintainable; duplicating them at the binary level is unreasonable bloat
(for avoidance of doubt, this is a sustained objection). Thus calls to
pthread_mutex_timedlock for 32-bit time must end up using syscalls with
64-bit time, because implementation approaches other than thin wrappers
round the 64-bit version are unreasonable.
I think the appropriate definition of a trivial interface for 32-bit time,
for which it's OK not to use a thin wrapper, is a syscall wrapper
generated through syscalls.list; anything requiring actual C code to
implement the function should be a thin wrapper round the version using
64-bit time rather than having a variant that just tries to use the 32-bit
syscall without attempting the 64-bit one.
As I said in <https://sourceware.org/ml/libc-alpha/2018-12/msg00144.html>,
the choice of syscalls behind a function in glibc has never been a stable
interface in glibc, and I don't think it ever reasonably can be a stable
interface; you have to use the dynamic symbol table to identify whether a
binary is using interfaces for 32-bit time, rather than basing things on
what syscalls it uses at runtime.
--
Joseph S. Myers
joseph@codesourcery.com