[Top] [All Lists]

Re: [parisc-linux] [patch 12/44] generic sched_find_first_bit()

To: Akinobu Mita <>
Subject: Re: [parisc-linux] [patch 12/44] generic sched_find_first_bit()
From: Grant Grundler <>
Date: Thu, 2 Feb 2006 20:58:22 -0700
Cc:,,, Ian Molton <>, David Howells <>,, Greg Ungerer <>,, Miles Bader <>, Linus Torvalds <>, Yoshinori Sato <>, Hirokazu Takata <>,,, Chris Zankel <>,,, Andi Kleen <>,,, Russell King <>,
In-reply-to: <20060201090325.497639000@localhost.localdomain>
Original-recipient: rfc822;
References: <20060201090224.536581000@localhost.localdomain> <20060201090325.497639000@localhost.localdomain>
User-agent: Mutt/1.5.9i
On Wed, Feb 01, 2006 at 06:02:36PM +0900, Akinobu Mita wrote:
> This patch introduces the C-language equivalent of the function:
> int sched_find_first_bit(const unsigned long *b);

Akinobu, would you prefer this is a slightly cleaner way?
(Not compile tested)

static inline int sched_find_first_bit(const unsigned long *b)
        if (unlikely(b[0]))
                return __ffs(b[0]);
        if (unlikely(b[1]))
                return __ffs(b[1]) + BITS_PER_LONG;
#if BITS_PER_LONG == 32
        if (unlikely(b[2]))
                return __ffs(b[2]) + 64;
        if (b[3])
                return __ffs(b[3]) + 96;
        return __ffs(b[128/BITS_PER_LONG]) + 128;

If BITS_PER_LONG isn't defined, the link step will fail and point
at a some unknown .o as the offender. But it's the responsibility
of the header file to make sure it's including the BITS_PER_LONG
definition, not the code that calls sched_find_first_bit().


<Prev in Thread] Current Thread [Next in Thread>