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.
This brings the call to an actually usable speed. Quick unscientific benchmark: 14ns : 102ns :: vDSO : syscall
This is a GNU extension, but a fairly minor one, for a system call that otherwise has no libc wrapper.
these functions are expected to return an error code rather than setting errno and returning -1.
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 is no longer used for anything, and reportedly clashed with a builtin on certain compilers.
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.