On Mon, 2008-04-21 at 22:14 +0200, Ingo Molnar wrote:
Hang on; this doesn't looks like such a good idea. Why don't the
definitions match? CPU type maps are supposed to be of type cpumask_t,
so why bother reinventing a physid_mask_t which is essentially a cut and
paste cpumask_t but on MAX_APICS instead of NR_CPUS ... surely we don't
have to have that duplication ... particularly as m32r has gone and
copied your definitions.
I'm guessing you want large sparse phys maps and smaller logical cpumaps
(although I'm not clear which archs can have a greater physical id than
they support as cpus)? In which case, it still makes sense for this to
be generic, using similar code in linux/cpumask.h to avoid further
duplication?
James
--