Re: Fifth draft of the Y2038 design document

[Albert ARIBAUD <albert dot aribaud at 3adev dot 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