lkml.org 
[lkml]   [2004]   [Aug]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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/

\
 
 \ /
  Last update: 2005-03-22 14:04    [W:0.052 / U:0.136 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site