| commit | 752fca5874f4ec7f25c7052224dda9b58db5b3ac | |
| author | zrj <rimvydas.jasinskas@gmail.com> | |
| Tue, 19 Jul 2016 07:07:45 +0000 (19 10:07 +0300) | ||
| committer | Matthew Dillon <dillon@apollo.backplane.com> | |
| Wed, 27 Jul 2016 00:27:26 +0000 (26 17:27 -0700) | ||
| tree | 824941824d8d285c086a55653017cb14eaf80c0d | treesnapshot (tar.gz zip) |
| parent | 38d8acb8eea2ddd5388322d3ef399687299f727d | commitdiff |
sys: Extract CPUMASK macros to new <machine/cpumask.h>
There are plenty enough CPUMASK macros already for them to have their own header.
So far only userspace users are powerd(8), usched(8) and kern_usched.c(VKERNEL64).
After recent change to expose kernel internal CPUMASK macros those got available
for userland codes even through <time.h> header. It is better to avoid that.
Also this reduces POSIX namespace pollution and keeps cpu/types.h header slim.
For now leave CPUMASK_ELEMENTS (not sure about ASSYM() macro handling the _ prefix)
and cpumask_t typedef (forward decl of struct cpumask would be better in prototypes).
There are plenty enough CPUMASK macros already for them to have their own header.
So far only userspace users are powerd(8), usched(8) and kern_usched.c(VKERNEL64).
After recent change to expose kernel internal CPUMASK macros those got available
for userland codes even through <time.h> header. It is better to avoid that.
Also this reduces POSIX namespace pollution and keeps cpu/types.h header slim.
For now leave CPUMASK_ELEMENTS (not sure about ASSYM() macro handling the _ prefix)
and cpumask_t typedef (forward decl of struct cpumask would be better in prototypes).