PERFORCE change 124529 for review

[Roman Divacky]

> > cpumaskt_t is just an unsigned int so ~0 should be fine.
> 
> For now. ;-) I was thinking about increasing it some time after 7.0 
> branching.  It is very clear that we will need it soon, i.e., 
> multicore CPUs are becoming more common these days.  FreeBSD/sun4v 
> already hit the limit with just one processor:
> 
> http://www.fsmware.com/sun4v/dmesg_latest.txt
> 
> Even on amd64/i386 world, we will hit it very soon, e.g., octal-core * 
> quad-socket => 32 cores.  Without increasing the sizeof(cpumask_t) 
> and/or grouping physical cores per socket, we won't be able to 
> survive very long.
 
yeah yeah.. ;) maybe we can use the same trick linux did. anyway its ok
now.

> > in FreeBSD it doesnt make any sense to emulate linux size because
> > if fbsd doesnt support that many CPUs we cannot emulate it. So
> > using fbsd-sized cpumask_t and telling userland about it is ok.
> >
> > agree?
> 
> Agreed, for 7.0.  We should fix it later when we add something like 
> sched_{get,set}affinity() syscalls.
 
http://people.freebsd.org/~ssouhlal/testing/setaffinity-20070707.diff

I already asked attilio@ to review it and hopefully do something about it.


> > thnx for the review!
> 
> Thank you!

so... do you agree that the current revision is fine. I need this to get kib@
to commit this...

thank you

roman