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

On Sun, Aug 01, 2004 at 06:05:29AM -0700, Paul Jackson wrote:
> 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.

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


-- wli

  reply	other threads:[~2004-08-01 13:10 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 [this message]
2004-08-01 13:36           ` Paul Jackson
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=20040801131004.GT2334@holomorphy.com \
    --to=wli@holomorphy.com \
    --cc=akpm@osdl.org \
    --cc=colpatch@us.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pj@sgi.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.