All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paul Jackson <pj@sgi.com>
To: William Lee Irwin III <wli@holomorphy.com>
Cc: zwane@linuxpower.ca, linux-kernel@vger.kernel.org, akpm@osdl.org,
	colpatch@us.ibm.com
Subject: Re: [PATCH][2.6] first/next_cpu returns values > NR_CPUS
Date: Sun, 1 Aug 2004 06:36:32 -0700	[thread overview]
Message-ID: <20040801063632.66c49e61.pj@sgi.com> (raw)
In-Reply-To: <20040801131004.GT2334@holomorphy.com>

> A strong majority return BITS_PER_LONG-aligned results in this case.

You mean, in Zwane's example, we'd see a return from any_online_cpu() of
32 or 64, not 3 (his NR_CPUS), and not just on i386, but on a majority
of arch's.  That's what you're saying, right?

Ok ... that favors your preference, teaching the users of find_next_bit
to be more tolerant.

Darn.  Your min(nbits, ...) patch looks good, but more is needed.

And could you make it:

+	return min(nbits, find_next_bit(srcp->bits, nbits, n+1));

rather than:

+	return min(NR_CPUS, find_next_bit(srcp->bits, nbits, n+1));

for consistency of presentation?  All the cpu and node mask macros of
this form (#define wrapped static inline) use the inline's parameter
names in the body of the inline, not what the define passed as those
params, including another 'nbits' in this very line of code.

-- 
                          I won't rest till it's the best ...
                          Programmer, Linux Scalability
                          Paul Jackson <pj@sgi.com> 1.650.933.1373

  reply	other threads:[~2004-08-01 13:37 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-07-31 20:52 [PATCH][2.6] first/next_cpu returns values > NR_CPUS Zwane Mwaikambo
2004-07-31 20:57 ` William Lee Irwin III
2004-07-31 23:02   ` Zwane Mwaikambo
2004-08-01  6:21 ` Paul Jackson
2004-08-01  7:22   ` Zwane Mwaikambo
2004-08-01 11:20     ` Paul Jackson
2004-08-01 14:51       ` Zwane Mwaikambo
2004-08-01 12:40     ` William Lee Irwin III
2004-08-01 13:05       ` Paul Jackson
2004-08-01 13:10         ` William Lee Irwin III
2004-08-01 13:36           ` Paul Jackson [this message]
2004-08-01 13:41             ` William Lee Irwin III
2004-08-01 13:47               ` Paul Jackson
2004-08-02 22:00               ` Matthew Dobson
2004-08-05 16:50                 ` OGAWA Hirofumi
2004-08-05 17:01                   ` William Lee Irwin III
2004-08-05 17:42                   ` Andrew Morton
2004-08-05 18:13                     ` Roman Zippel
2004-08-01 14:54       ` Zwane Mwaikambo
2004-08-01 15:05         ` William Lee Irwin III

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20040801063632.66c49e61.pj@sgi.com \
    --to=pj@sgi.com \
    --cc=akpm@osdl.org \
    --cc=colpatch@us.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=wli@holomorphy.com \
    --cc=zwane@linuxpower.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.