On Fri, 13 Jul 2007 01:29:06 -0700 Paul Jackson <[EMAIL PROTECTED]> wrote:
> > I'm scratching my head over that min_t in __first_node(), too. I don't > > think > > it's possible for find_first_bit(..., N) to return anything >N _anyway_. > > And if > > it does, we want to know about it. > > > > <looks at Paul> > > I'm not sure I've got this right, but looks like that min_t went in after > Zwane Mwaikambo, then <[EMAIL PROTECTED]>, whom I am presuming is the same > person as now at <[EMAIL PROTECTED]>, found a problem with the i386 > find_next_bit implementation returning > N when merging i386 cpu hotplug. Ah, Zwane was involved - say no more ;) > See the thread: > > http://lkml.org/lkml/2004/7/31/102 > [PATCH][2.6] first/next_cpu returns values > NR_CPUS > > I apparently lobbied at the time to mandate that find_first_bit(..., N) > return exactly N on failure to find a set bit, but gave up, after some > confusions on my part. iirc, find_first_bit(..., N) _must_ return N on nothing-found. It'd be untidy to return some randomly-larger number. I wonder which was the culpable architecture? Oh, i386. Note how the i386 implementation's documentation carefully avoids describing the return value. I don't think _any_ of our find_foo_bit() implementations have return-value docs, and here we see the result. Sigh. What crap. I guess we leave it as-is. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/