Re: [PATCH][2.6] first/next_cpu returns values > NR_CPUS

From: Paul Jackson
Date: Sun Aug 01 2004 - 08:37:59 EST


> A strong majority return BITS_PER_LONG-aligned results in this case.

You mean, in Zwane's example, we'd see a return from any_online_cpu() of
32 or 64, not 3 (his NR_CPUS), and not just on i386, but on a majority
of arch's. That's what you're saying, right?

Ok ... that favors your preference, teaching the users of find_next_bit
to be more tolerant.

Darn. Your min(nbits, ...) patch looks good, but more is needed.

And could you make it:

+ return min(nbits, find_next_bit(srcp->bits, nbits, n+1));

rather than:

+ return min(NR_CPUS, find_next_bit(srcp->bits, nbits, n+1));

for consistency of presentation? All the cpu and node mask macros of
this form (#define wrapped static inline) use the inline's parameter
names in the body of the inline, not what the define passed as those
params, including another 'nbits' in this very line of code.

--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <pj@xxxxxxx> 1.650.933.1373
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/