Bug 173945

In RHEL4U3, we are increasing in the kernel, the number of supported CPUs to be
above 64 for PPC and Itanium.  In the course of investigating the side-effects,
Ingo pointed out that the manpage for sched_[set|get]affinity is quite
disorganized.  Here's an excerpt from his mail:

current glibc APIs properly support up to 1024 CPUs, see
/usr/include/bits/sched.h:

 #if defined _SCHED_H && !defined __cpu_set_t_defined
 # define __cpu_set_t_defined
 /* Size definition for CPU sets.  */
 # define __CPU_SETSIZE  1024
 # define __NCPUBITS     (8 * sizeof (__cpu_mask))

so the problem is not technical but more psychological. If you type:
 
   man sched_setaffinity

on a FC4 box, the manpage starts with:

SYNOPSIS
       #include <sched.h>

       int  sched_setaffinity(pid_t  pid,  unsigned  int  len,  unsigned  long
       *mask);

       int  sched_getaffinity(pid_t  pid,  unsigned  int  len,  unsigned  long
       *mask);

which is the old 'wrong' API that limits things to 64 CPUs. Only further 
down, in the 'HISTORY' section is the real API described:

       /* Set the CPU affinity for a task */
       extern int sched_setaffinity (pid_t pid, size_t cpusetsize,
                                     const cpu_set_t *cpuset);

       /* Get the CPU affinity for a task */
       extern int sched_getaffinity (pid_t pid, size_t cpusetsize,
                                     cpu_set_t *cpuset);

i'd not be surprised if there were a number of applications that still 
used the following type of code:

 #define __USE_GNU
 #include <sched.h>

 int main (void)
 {
         int cpu = 10;
         unsigned long mask = 1 << cpu;

         // bind to CPU#10:
         if (sched_setaffinity(0, sizeof(mask), &mask)) {
                 perror("error!\n");
                 exit(1);
         }

         return 0;
 }

the above code, if compiled with -Wall, will give this warning:

 warning: passing argument 3 of 'sched_setaffinity' from incompatible pointer type

but the code will otherwise link and run fine, and will handle cpu values
0-63. How widespread this problem is - i dont know, maybe the glibc folks 
have some estimation.