Posix compliant process clock patch for the linux arch in glibc

[Christoph Lameter]

On Fri, 22 Oct 2004, Andreas Jaeger wrote:

> Looking at your code, I do not understand how a glibc with your patch
> will work on a kernel that does not have the 2.6.10 patches in it?

All the clocks will work except for the CLOCK_*_CPUTIME_ID clocks.

> > -  *clockid = CLOCK_THREAD_CPUTIME_ID | (pd->tid << CLOCK_IDFIELD_SIZE);
> > +  *clockid = - (pd->tid + PID_MAX_LIMIT);
>
> The above will only work if the running kernel has your patch in it.
> For older kernels, it will break.  This is not acceptable and the code
> has to be written in such a way that it works in both cases.
>
> So, how can we figure out that we're running a fixed kernel?

Older kernels do not support process/thread clocks and will return EINVAL.
This is the same behavior as now.

> You should do the following:
> - Have a look at sysdeps/unix/sysv/linux/kernel-features.h
> - add an __ASSUME_POSIX_CLOCK to kernel-features.h

I already added an __ASSUME_POSIX_IMPROVED in there.
Please look further down.

> - Write your code so that you do the following (check other files in
>   the linux subdirectoy how this is done:
>
> #if __ASSUME_POSIX_CLOCK
>   your new code
> #else
>   static int have_posix_clock = -1;
>   if (have__support_posix_clock < 0)
>     check whether kernel contains your code, save it in the var
>   if (have__support_posix_clock)
>     ...
>   else
>     ...
>
>   Depending on your check, there might be other ways to write the code
>   (check e.g. ftruncate64.c).
>
> Without these changes, your patch is not usable to add to glibc.
> People want to have one glibc that runs on any kernel...

Glibc will run on any kernel even with this patch. It just will stop
returning results from CLOCK_*_CPUTIME_ID that are not posix compliant.
This is intended behavior as explained in the post.