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

[Paul Jackson]

William wrote:
> Maybe the few callers that are sensitive to the precise return value
> should use min_t(int, NR_CPUS, ...) instead of all callers taking the
> branch on behalf of those few.

Either way - we need consistency.  Either find_next_bit(.., size, ...)
returns exactly size if no more bits, or all its callers tolerate any
return >= size.

I probably prefer the former, because I expect slightly tighter kernel
code now (see my previous post on text size), and fewer bugs in the
future (more clients of find_next_bit will be coded than new
implementations of it), if we go this way.  William's comments suggest
to me he prefers the later.

Either (or both) seems better than what we have.

William - can you read the find_next_bit() implementations in some other
arch's well enough to understand if they are anal about returning
exactly 'size', or content to return something >= size, when they run
out of bits?  That code was a bit denser than I could deal with easily.

If a strong majority of the arch's find_next_bit() are anal, or on the
other hand, are not, then I'd suggest we follow their lead.

-- 
                          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/