Messages in this thread | | | Date | Sun, 1 Aug 2004 06:05:29 -0700 | From | Paul Jackson <> | Subject | Re: [PATCH][2.6] first/next_cpu returns values > NR_CPUS |
| |
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@sgi.com> 1.650.933.1373 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |