sched.h: Fix _S macros for better compatibility with glibc.

[dchagin]

Summary

The macros whose names end with "_S" operate on the dynamically allocated
CPU set(s) whose size is setsize bytes.

Test Plan

glibc affinity tests

[jhb]

tests/sys/kern/sched_affinity.c

9

This seems unneeded? Plus, you should only include one of <sys/param.h> or <sys/types.h> but not both.

[kib]

I do not quite understand the change. Isn't it breaking all consumers of the modified macros? At very least, I see a lot of uses for CPU_.*_S in tests/sys/kern/sched_affinity.c

sys/sys/cpuset.h

87–90

[dchagin]

Fix tests, i planned to do it after, but not a problem to fix it now.

[dchagin]

brackets around _s

[dchagin]

In D38110#866210, @kib wrote:

I do not quite understand the change. Isn't it breaking all consumers of the modified macros? At very least, I see a lot of uses for CPU_.*_S in tests/sys/kern/sched_affinity.c

https://cgit.freebsd.org/src/commit/sys/sys/cpuset.h?id=e2650af157bc7489deaf2c9054995f0f88a6e5da added _S macro for compatibility with GLIBC, but it's still incompatible as glibc uses cpusetsize in bytes, not in bits.

[kib]

sys/sys/cpuset.h

80

WFIW, e.g. _bitset.h uses 8 instead of NBBY. At least, this avoids more user namespace pollution. Also I do not quite understand the #ifndef guards there, and limiting that to non-kernel case.

[dchagin]

fixed, thanks. Should I ask for exp-run?

[kib]

In D38110#868670, @dchagin wrote:

fixed, thanks. Should I ask for exp-run?

What do you expect to catch with the exp-run? It is runtime change, you multiply the input arg by eight.