sys/_{cpu,domain}set.h: don't require sys/param.h

Add machine/param.h for MAXCPU and MAXMEMDOM in the _KERNEL case of
sys/_cpuset.h and sys/_domainset.h, making them more self contained.

This eliminates the need to include sys/param.h before sys/cpuset.h and
sys/domainset.h.

Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D44466

sys: Remove $FreeBSD$: two-line .h pattern

Remove /^\s*\*\n \*\s+\$FreeBSD\$$\n/

cpuset: increase userland maximum size to 1024

Hardware with more than 256 CPU cores is now available and will become
increasingly common. Bump CPU_MAXSIZE (used for userland cpuset_t
sizing) to 1024 to define the ABI for FreeBSD 14.

This change is reapplied after a change to decouple cpuset from bhyve:
commit e17eca327633 ("vmm: Avoid embedding cpuset_t ioctl ABIs").

PR: 269572, 271213 [exp-run]
Reviewed by: mjg, jhb
Relnotes: yes
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D39941

(cherry picked from commit 76887e84be975698b14699d7d0dfb157d73e9990)

spdx: The BSD-2-Clause-FreeBSD identifier is obsolete, drop -FreeBSD

The SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier. Catch
up to that fact and revert to their recommended match of BSD-2-Clause.

Discussed with: pfg
MFC After: 3 days
Sponsored by: Netflix

Revert "cpuset: increase userland maximum size to 1024"

This reverts commit 76887e84be975698b14699d7d0dfb157d73e9990.

struct vm_exit currently requires that cpuset_t be identical in userland
and kernel. This will be recommitted after these are decoupled.

PR: 271330, 269572
Reported by: corvink
Sponsored by: The FreeBSD Foundation

cpuset: increase userland maximum size to 1024

Hardware with more than 256 CPU cores is now available and will become
increasingly common. Bump CPU_MAXSIZE (used for userland cpuset_t
sizing) to 1024 to define the ABI for FreeBSD 14.

PR: 269572, 271213 [exp-run]
Reviewed by: mjg, jhb
Relnotes: yes
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D39941

sys/sys/cpuset.h

Fix typo in source file.

Reported by: pluknet at gmail.com (Sergey Kandaurov)

Make CPU_SET macros compliant with other implementations

The introduction of <sched.h> improved compatibility with some 3rd
party software, but caused the configure scripts of some ports to
assume that they were run in a GLIBC compatible environment.

Parts of sched.h were made conditional on -D_WITH_CPU_SET_T being
added to ports, but there still were compatibility issues due to
invalid assumptions made in autoconfigure scripts.

The differences between the FreeBSD version of macros like CPU_AND,
CPU_OR, etc. and the GLIBC versions was in the number of arguments:
FreeBSD used a 2-address scheme (one source argument is also used as
the destination of the operation), while GLIBC uses a 3-adderess
scheme (2 source operands and a separately passed destination).

The GLIBC scheme provides a super-set of the functionality of the
FreeBSD macros, since it does not prevent passing the same variable
as source and destination arguments. In code that wanted to preserve
both source arguments, the FreeBSD macros required a temporary copy of
one of the source arguments.

This patch set allows to unconditionally provide functions and macros
expected by 3rd party software written for GLIBC based systems, but
breaks builds of externally maintained sources that use any of the
following macros: CPU_AND, CPU_ANDNOT, CPU_OR, CPU_XOR.

One contributed driver (contrib/ofed/libmlx5) has been patched to
support both the old and the new CPU_OR signatures. If this commit
is merged to -STABLE, the version test will have to be extended to
cover more ranges.

Ports that have added -D_WITH_CPU_SET_T to build on -CURRENT do
no longer require that option.

The FreeBSD version has been bumped to 1400046 to reflect this
incompatible change.

Reviewed by: kib
MFC after: 2 weeks
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D33451

sys/bitset.h: reduce visibility of BIT_* macros

Add two underscore characters "__" to names of BIT_* and BITSET_*
macros to move them to the implementation name space and to prevent
a name space pollution due to BIT_* macros in 3rd party programs with
conflicting parameter signatures.

These prefixed macro names are used in kernel header files to define
macros in e.g. sched.h, sys/cpuset.h and sys/domainset.h.

If C programs are built with either -D_KERNEL (automatically passed
when building a kernel or kernel modules) or -D_WANT_FREENBSD_BITSET
(or this macros is defined in the source code before including the
bitset macros), then all macros are made visible with their previous
names, too. E.g., both __BIT_SET() and BIT_SET() are visible with
either of _KERNEL or _WANT_FREEBSD_BITSET defined.

The main reason for this change is that some 3rd party sources
including sched.h have been found to contain conflicting BIT_*
macros.

As a work-around, parts of shed.h have been made conditional and
depend on _WITH_CPU_SET_T being set when sched.h is included.
Ports that expect the full functionality provided by sched.h need
to be built with -D_WITH_CPU_SET_T. But this leads to conflicts if
BIT_* macros are defined in that program, too.

This patch set makes all of sched.h visible again without this
parameter being passed and without any name space pollution due
to BIT_* macros becoming visible when sched.h is included.

This patch set will be backported to the STABLE branches, but ports
will need to use -D_WITH_CPU_SET_T as long as there are supported
releases that do not contain these patches.

Reviewed by: kib, markj
MFC after: 1 month
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D33235

sys/sys: further adoption of SPDX licensing ID tags.

Mainly focus on files that use BSD 2-Clause license, however the tool I
was using misidentified many licenses so this was mostly a manual - error
prone - task.

The Software Package Data Exchange (SPDX) group provides a specification
to make it easier for automated tools to detect and summarize well known
opensource licenses. We are gradually adopting the specification, noting
that the tags are considered only advisory and do not, in any way,
superceed or replace the license texts.

Fix <sys/_bitset.h> and <sys/_cpuset.h> to not require <sys/param.h>.

- Hardcode '8' instead of NBBY in _BITSET_BITS.
- Define a private version of 'howmany' for use in __bitset_words().
- While here, move a few more things out of _bitset.h and _cpuset.h to
bitset.h and cpuset.h, respectively. The only things left in
_bitset.h and _cpuset.h are the bits needed to define a bitset
structure.

Reviewed by: bde, kib (ish)

Bump the default size of cpuset_t masks in userland from 128 bits to 256.

This should not be an ABI change since the various public APIs that use
cpusets all include an explicit size parameter in addition to the cpuset
parameter.

MFC after: 1 week

Generalize the bitset operations, present in cpuset and offer a KPI to
redefine such operations for different consumers.
This will be used when NUMA support will be finished and numaset
will need to be used.

Sponsored by: EMC / Isilon storage division
Obtained from: jeff
Reviewed by: alc

Post r222812 KTR_CPUMASK started being initialized only as a tunable
handler and not more statically.

Unfortunately, it seems that this is not ideal for new platform bringup
and boot low level development (which needs ktr_cpumask to be effective
before tunables can be setup).

Because of this, add a way to statically initialize cpusets, by passing
an list of initializers, divided by commas. Also, provide a way to enforce
an all-set mask, for above mentioned initializers.

This imposes some differences on how KTR_CPUMASK is setup now as a
kernel option, and in particular this makes the words specifications
backward wrt. what is currently in -CURRENT. In order to avoid mismatches
between KTR_CPUMASK definition and other way to setup the mask
(tunable, sysctl) and to print it, change the ordering how
cpusetobj_print() and cpusetobj_scan() acquire the words belonging
to the set.
Please give a look to sys/conf/NOTES in order to understand how the
new format is supposed to work.

Also, ktr manpages will be updated shortly by gjb which volountereed
for this.

This patch won't be merged because it changes a POLA (at least
from the theoretical standpoint) and this is however a patch that
proves to be effective only in development environments.

Requested by: rpaulo
Reviewed by: jeff, rpaulo

Revert this, as in userland MAXCPU is always 1.

Reported by: marcel

Commit the support for removing cpumask_t and replacing it directly with
cpuset_t objects.
That is going to offer the underlying support for a simple bump of
MAXCPU and then support for number of cpus > 32 (as it is today).

Right now, cpumask_t is an int, 32 bits on all our supported architecture.
cpumask_t on the other side is implemented as an array of longs, and
easilly extendible by definition.

The architectures touched by this commit are the following:
- amd64
- i386
- pc98
- arm
- ia64
- XEN

while the others are still missing.
Userland is believed to be fully converted with the changes contained
here.

Some technical notes:
- This commit may be considered an ABI nop for all the architectures
different from amd64 and ia64 (and sparc64 in the future)
- per-cpu members, which are now converted to cpuset_t, needs to be
accessed avoiding migration, because the size of cpuset_t should be
considered unknown
- size of cpuset_t objects is different from kernel and userland (this is
primirally done in order to leave some more space in userland to cope
with KBI extensions). If you need to access kernel cpuset_t from the
userland please refer to example in this patch on how to do that
correctly (kgdb may be a good source, for example).
- Support for other architectures is going to be added soon
- Only MAXCPU for amd64 is bumped now

The patch has been tested by sbruno and Nicholas Esborn on opteron
4 x 12 pack CPUs. More testing on big SMP is expected to came soon.
pluknet tested the patch with his 8-ways on both amd64 and i386.

Tested by: pluknet, sbruno, gianni, Nicholas Esborn
Reviewed by: jeff, jhb, sbruno

Revert by accident r221441.

Remove the previously added comment.
Probabilly me is the only one who didn't know userland and kerneland sizes
were mismatching.