This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Fifth draft of the Y2038 design document
- From: Albert ARIBAUD <albert dot aribaud at 3adev dot fr>
- To: Joseph Myers <joseph at codesourcery dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Wed, 1 Mar 2017 08:11:19 +0100
- Subject: Re: Fifth draft of the Y2038 design document
- Authentication-results: sourceware.org; auth=none
- References: <20170222090511.48be22ed.albert.aribaud@3adev.fr> <alpine.DEB.2.20.1702221647560.8704@digraph.polyomino.org.uk> <20170222194855.7581deca.albert.aribaud@3adev.fr> <alpine.DEB.2.20.1702222055440.24643@digraph.polyomino.org.uk> <20170223131634.06fa476c.albert.aribaud@3adev.fr> <alpine.DEB.2.20.1702231418320.15395@digraph.polyomino.org.uk> <20170223165052.1b494e3a.albert.aribaud@3adev.fr>
On Thu, 23 Feb 2017 16:50:52 +0100, Albert ARIBAUD
<albert.aribaud@3adev.fr> wrote :
> Hi Joseph,
>
> On Thu, 23 Feb 2017 14:21:22 +0000, Joseph Myers
> <joseph@codesourcery.com> wrote :
>
> > On Thu, 23 Feb 2017, Albert ARIBAUD wrote:
> >
> > > - a [32-bit-time] implementation of 'int clock_gettime(clockid_t,
> > > struct timespec *tp)' exists, and is referred to by the implementation
> > > symbol '__clock_gettime'.
> > >
> > > - 'clock_gettime' redirects to '__clock_gettime'.
> >
> > No, it doesn't redirect. User application code is compiled to .o files
> > that reference clock_gettime, not __clock_gettime. __clock_gettime is a
> > GLIBC_PRIVATE symbol, only for internal use by glibc libraries when
> > required for namespace reasons, not for application code. Whereas
> > __clock_gettime64 would have a public GLIBC_2.X symbol version since
> > references to it would be generated by redirections in headers when the
> > user defines a feature test macro supported for user code.
>
> Thanks for the rectification; I think now I have the terminology and
> concepts straight, and -- assuming the rest is correct -- I will edit
> the document for next review.
Further thought on API vs implementation declarations:
GLIBC needs to provide 64-bit-time clock_gettime to 32-bit code in
various run-time cases:
- above an 'old', only 32-bit-time, kernel;
- above a 'new', mixed 64- and 32-bit-time, kernel;
- above a 'newer', only 64-bit time, kernel.
So, the 64-bit time clock_gettime GLIBC implementation must be able to
invoke both the 64-bit time 'clock_gettime64' syscall and the 32-bit
time 'clock_gettime' syscall, and pass each one the right argument type.
This means the GLIBC implementation of clock_gettime64 needs to know
not only the GLIBC 'struct timespec', but also the two Linux 'struct
timespec' and 'struct timespec64'.
I've looked at how GLIBC solves this for 'struct stat' / 'struct
stat64', but there, the variant chosen depends on the word size, i.e.
it's *either* the 32-bit off_t *or* the 64-bit off64_t, not both at the
same time.
Whereas for struct timespec, we need definition for both of the kernel's
'struct timespec' *and* 'struct timespec64' *in addition* to the GLIBC
API 'struct timespec'.
'struct timespec64' poses no problem, as it is not used in the GLIBC
API, so I can get it from kernel headers without clashing with any
GLIBC-declared name.
'struct timespec', OTOH, is declared both by the kernel to denote the
32-bit-time-only variant for the 'old' syscall) and by the GLIBC API
to denote the 32- or 64-bit time version depending on __USE_TIME_BITS64.
My first hunch to solve this name conflict is to keep 'struct timespec'
for GLIBC API and rename the kernel's 'struct timespec'; one way to do
this would be to trick the kernel headers themselves into this
renaming, by doing e.g. a
#define timespec __kernel_timespec
before including kernel headers in the clock_gettime implementation
code, and then passing a struct __kernel_timespec to the kernel's 'old'
32-bit-time clock_gettime syscall.
But I'm not sure this is an admissible way to do it, and if it is, I'm
wondering if there isn't a better one.
Any comments?
Cordialement,
Albert ARIBAUD
3ADEV