This is the mail archive of the libc-hacker@sources.redhat.com mailing list for the glibc project.

Note that libc-hacker is a closed list. You may look at the archives of this list, but subscription and posting are not open.


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: Whats up with _POSIX_CPUTIME


On Tue, Nov 30, 2004 at 02:16:08PM -0600, Steve Munroe wrote:
> Whats up with _POSIX_CPUTIME and _POSIX_THREAD_CPUTIME?
> 
> powerpc/powerpc64 builds are failing because they are undefined. So far 
> only i386, ia64, and x86_64 define these in posix_opt.h.
> 
> Is these just missing #ifdef or do I need to enable something for powerpc. 
> If so is there a pointer to a description of this feature.

http://www.opengroup.org/onlinepubs/009695399/basedefs/unistd.h.html
says about these macros that they can be:
1) undefined, then sysconf() can be used to determine whether the option
   is present at runtime, no words about whether the headers/functions/macros/etc.
   are available though
2) defined to -1, then the option is not supported, headers/functions/macros/etc.
   need not be present
3) defined to 0, then headers/functions/macros/etc. must be present, but the
   option is not necessarily supported, so sysconf() should be used to
   detect whether the option is supported at runtime
4) defined to > 0 (200112L) - the option is unconditionally supported

Now, for _POSIX_CPUTIME/_POSIX_THREAD_CPUTIME, we have the
headers/functions/macros/etc. required for these options always present.
On i?86/x86_64/ia64 the option is sometimes supported (so
#define _POSIX_CPUTIME 0 is correct), while on ppc/ppc64/s390/s390x etc.
we don't define it at all.  But 1) is almost like 3) when we have the
headers/data types/functions, so either we can #define these to 0
on all Linux platforms and use some other (not exported) macro to tell
posix-timer.h, timer_*.c etc. whether they should attempt something
or not (this would have 2 advantages, the bigger that we could unify
all the linuxthreads and all the nptl posix_opt.h headers, but also that
e.g. we could decide in the future to use a tick register say on ppc*
on hardware that has it (do I remember well that there is something like
that on some ppc's?) usable without the need to recompile apps to use it,
or we can #define it to -1 to say that it is really not supported.

	Jakub


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