as with clock_getres, the time64 syscall for this is not necessary or
useful, this time since scheduling timeslices are not on the order 68
years. if there's a 32-bit syscall, use it and expand the result into
timespec; otherwise there is only one syscall and it does the right
thing to store to timespec directly.
on 64-bit archs, there is no change to the code after preprocessing.
the sched_getaffinity syscall only fills a cpu set up to the set size
used/supported by the kernel. the rest is left untouched and userspace
is responsible for zero-filling it based on the return value of the
syscall.
this first commit just includes the CPU_* and sched_* interfaces, not
the pthread_* interfaces, which may be added later. simple
sanity-check testing has been done for the basic interfaces, but most
of the macros have not yet been tested.
linux's sched_* syscalls actually implement the TPS (thread
scheduling) functionality, not the PS (process scheduling)
functionality which the sched_* functions are supposed to have.
omitting support for the PS option (and having the sched_* interfaces
fail with ENOSYS rather than omitting them, since some broken software
assumes they exist) seems to be the only conforming way to do this on
linux.
Rich Felker
Nathan Zadoks