[PATCH] Add the infrastructure for supporting an infinite number of CPUs

Current maximum number of CPUs supported by the FreeBSD kernel is 32.
That number cames from indirectly by the fact that we have a cpumask_t
type, representing a mask of CPUs, which is an unsigned int right now.
I then made a patch that removes the cpumask_t type and uses cpuset_t
type for characterizing a generic mask of CPUs:
http://www.freebsd.org/~attilio/largeSMP/largeSMP-patchset-beta-0.diff

This is part of a bigger effort which brought to serveral smaller
commits along the way, in order to fix some edge cases.

Things to pay attention at:
- Userland and kerneland cpuset_t size can be different, thus when
accessing to a kernel cpuset_t object from userland (via kvm_read()
for example) a pattern similar to what pmccontrol does, in this patch,
should be followed
- There are some cpuset_t object in pcpu representing curcpu mask and
!curcpu mask. With transition from cpumask_t to cpuset_t they become
inefficient and not really useful. The next weeks I'll focus on
removing them and make a smarter usage of the cpuset_t interface.
Additively, please note that  right now I clobbered pcpu accesses
under scheduler pinnings, because it is possible more than a single
atomic operation is needed for accessing a cpuset_t. When the cleanup
happens those pinnings will go away.
- I had to introduce, among the other things, functions for
representing cpuset_t object in "visual" way, thus
cpusetobj_strprint() and cpusetobj_strscan(). I got the desired format
from what Linux already does, so that someone may be already used to
it. Anyway strings will be represented as a serie of long, hexadecimal
long words, all separated by ", ". The left-most represents the higher
word, following natural bits representation.
- I used cpusetobj_strscan() for implementing KTR_CPUMASK in a way it
supports cpuset_t. Change the kernel config appropriately.
- No MAXCPU has been bumped in the patch, but I encourage you to do so
with your own kernel configurations.

I really need to commit this patch before code slush happens, thus I
plan to commit it on June 7th, if no one reports bugs or can make good
point on his reviews. Please note that the patch has been greatly
tested and reviewed on all FreeBSD tier-1 and tier-2 architectures.
Anyway more testing and reviews are welcome to happen.

Thanks,
Attilio


-- 
Peace can only be achieved by understanding - A. Einstein