From: Nick Piggin <nickpiggin@yahoo.com.au>
To: Paul Jackson <pj@sgi.com>
Cc: rusty@rustcorp.com.au, linux-kernel@vger.kernel.org,
akpm@osdl.org, ak@muc.de, ashok.raj@intel.com, hch@infradead.org,
jbarnes@sgi.com, joe.korty@ccur.com, manfred@colorfullife.com,
colpatch@us.ibm.com, mikpe@csd.uu.se, Simon.Derr@bull.net,
wli@holomorphy.com
Subject: Re: [PATCH] cpumask 5/10 rewrite cpumask.h - single bitmap based implementation
Date: Fri, 04 Jun 2004 15:35:39 +1000 [thread overview]
Message-ID: <40C00A2B.1040606@yahoo.com.au> (raw)
In-Reply-To: <20040603223005.01bbab21.pj@sgi.com>
Paul Jackson wrote:
>>I don't see what you gain from having the cpumask type but having
>>to get at its internals with the bitop functions.
>
>
> The essential gain, in my view, of cpumask, is that it encapsulates
> the value NR_CPUS. cpumasks are bitmaps of length NR_CPUS.
>
> Yes, there is an open issue of whether cpumasks are worth it.
> I think enough code has taken to them that they are.
>
Yes, I'm all for the full cpumask abstraction.
> The getting at internals (via cpus_addr(), I'm guessing you mean)
> was a workaround for some code that messed with cpumasks and simple
> unsigned longs as if they were interoperable. "cpus_addr" should
> be marked deprecated, and its use coded out. Its remaining uses
> are in arch-specific areas where I lack the expertise and testing
> environment to accomplish such.
>
> I needed some legacy mechanism such as this, in order to avoid
> having such existing uses bring the entire cpumask overhaul to
> a screeching halt.
>
No, by getting at the internals, I mean the internals of the
type itself. Its implementation, if you will. (Well I guess
that also *includes* users getting the address and derefing it
as an unsigned long).
But no, I was talking about something more general. Rusty wrote:
>>+#define cpus_addr(src) ((src).bits)
>
>
> We've discussed this before when talking about whether it'd be easier to
> just make people use raw bitop functions directly, so I know we have
> philosophical differences here.
>
> So, opinion alert: if I were doing this, I'd probably live without this
> macro; in my mind it crosses the "too much abstraction" line. I did
> momentarily wonder what this macro did when I saw it used in the
> succeeding patches.
Now in my opinion, it is either all or nothing. I could be wrong,
but I don't think there is any point with a nice cpumask type if
you are just going to get inside it and do bitmap operations on it.
In summary, I think your patches are nice :)
next prev parent reply other threads:[~2004-06-04 5:35 UTC|newest]
Thread overview: 92+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-06-03 16:43 [PATCH] Bitmap and Cpumask Cleanup - Overview Paul Jackson
2004-06-03 17:05 ` [PATCH] cpumask 1/10 cpu_present_map real even on non-smp Paul Jackson
2004-06-03 17:09 ` [PATCH] cpumask 2/10 bitmap cleanup preparation for cpumask overhaul Paul Jackson
2004-06-03 17:09 ` [PATCH] cpumask 3/10 bitmap inlining and optimizations Paul Jackson
2004-06-03 17:09 ` [PATCH] cpumask 4/10 uninline find_next_bit on ia64 Paul Jackson
2004-06-03 17:10 ` [PATCH] cpumask 5/10 rewrite cpumask.h - single bitmap based implementation Paul Jackson
2004-06-04 0:07 ` Andrew Morton
2004-06-04 0:25 ` Andrew Morton
2004-06-04 2:58 ` Paul Jackson
2004-06-04 2:47 ` Paul Jackson
2004-06-04 2:54 ` David S. Miller
2004-06-04 5:02 ` Paul Jackson
2004-06-04 5:01 ` David S. Miller
2004-06-04 1:47 ` Rusty Russell
2004-06-04 2:02 ` Nick Piggin
2004-06-04 2:19 ` Rusty Russell
2004-06-04 5:18 ` Paul Jackson
2004-06-04 5:22 ` David S. Miller
2004-06-04 6:57 ` Paul Jackson
2004-06-04 9:31 ` Mikael Pettersson
2004-06-04 9:37 ` William Lee Irwin III
2004-06-04 9:46 ` Mikael Pettersson
2004-06-04 9:59 ` William Lee Irwin III
2004-06-04 11:16 ` Mikael Pettersson
2004-06-04 11:27 ` William Lee Irwin III
2004-06-04 11:32 ` William Lee Irwin III
2004-06-04 16:23 ` Paul Jackson
2004-06-04 16:28 ` William Lee Irwin III
2004-06-04 17:47 ` Paul Jackson
2004-06-04 18:12 ` William Lee Irwin III
2004-06-04 18:20 ` William Lee Irwin III
2004-06-04 18:27 ` Andrew Morton
2004-06-04 18:38 ` William Lee Irwin III
2004-06-05 2:51 ` William Lee Irwin III
2004-06-05 3:29 ` William Lee Irwin III
2004-06-04 18:42 ` Paul Jackson
2004-06-04 18:42 ` William Lee Irwin III
2004-06-05 6:48 ` Paul Jackson
2004-06-06 2:07 ` Rusty Russell
2004-06-06 12:16 ` Paul Jackson
2004-06-06 12:13 ` William Lee Irwin III
2004-06-06 12:28 ` Paul Jackson
2004-06-06 12:36 ` William Lee Irwin III
2004-06-06 13:42 ` Paul Jackson
2004-06-06 23:20 ` Rusty Russell
2004-06-07 6:44 ` Paul Jackson
2004-06-04 9:41 ` Andrew Morton
2004-06-05 7:01 ` Paul Jackson
2004-06-04 16:03 ` Paul Jackson
2004-06-04 16:56 ` William Lee Irwin III
2004-06-04 17:29 ` Paul Jackson
2004-06-04 17:52 ` William Lee Irwin III
2004-06-04 19:01 ` Paul Jackson
2004-06-04 19:08 ` Anton Blanchard
2004-06-04 19:17 ` William Lee Irwin III
2004-06-04 20:28 ` Andrew Morton
2004-06-07 7:55 ` Anton Blanchard
2004-06-05 7:28 ` Paul Jackson
2004-06-06 8:07 ` Paul Jackson
2004-06-06 8:16 ` William Lee Irwin III
2004-06-05 0:05 ` Paul Jackson
2004-06-05 1:31 ` William Lee Irwin III
2004-06-05 8:04 ` Paul Jackson
2004-06-05 8:26 ` William Lee Irwin III
2004-06-06 8:40 ` Paul Jackson
2004-06-06 12:34 ` Paul Jackson
2004-06-07 16:54 ` fix up compat_sched_[get/set]affinity Joe Korty
2004-06-07 17:07 ` William Lee Irwin III
2004-06-04 5:30 ` [PATCH] cpumask 5/10 rewrite cpumask.h - single bitmap based implementation Paul Jackson
2004-06-04 5:35 ` Nick Piggin [this message]
2004-06-04 5:40 ` Andrew Morton
2004-06-04 5:53 ` Nick Piggin
2004-06-04 6:47 ` Paul Jackson
2004-06-04 4:31 ` Paul Jackson
2004-06-04 8:19 ` William Lee Irwin III
2004-06-04 8:43 ` Keith Owens
2004-06-04 9:54 ` William Lee Irwin III
2004-06-04 17:08 ` Paul Jackson
2004-06-09 16:38 ` William Lee Irwin III
2004-06-04 9:14 ` Paul Jackson
2004-06-03 17:10 ` [PATCH] cpumask 6/10 remove 26 no longer used cpumask*.h files Paul Jackson
2004-06-03 17:10 ` [PATCH] cpumask 7/10 remove obsolete cpumask macro uses - i386 arch Paul Jackson
2004-06-03 17:10 ` [PATCH] cpumask 8/10 remove obsolete cpumask macro uses - other archs Paul Jackson
2004-06-03 17:11 ` [PATCH] cpumask 9/10 Remove no longer used obsolete macro emulation Paul Jackson
2004-06-03 17:11 ` [PATCH] cpumask 10/10 optimize various uses of new cpumasks Paul Jackson
2004-06-04 4:27 ` Rusty Russell
2004-06-04 4:40 ` Nick Piggin
2004-06-04 4:51 ` Paul Jackson
2004-06-09 0:09 ` PATCH] cpumask 11/10 comment, spacing tweaks Paul Jackson
-- strict thread matches above, loose matches on Subject: below --
2004-06-06 15:07 [PATCH] cpumask 5/10 rewrite cpumask.h - single bitmap based implementation Mikael Pettersson
2004-06-06 16:44 ` William Lee Irwin III
2004-06-06 17:46 ` Paul Jackson
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=40C00A2B.1040606@yahoo.com.au \
--to=nickpiggin@yahoo.com.au \
--cc=Simon.Derr@bull.net \
--cc=ak@muc.de \
--cc=akpm@osdl.org \
--cc=ashok.raj@intel.com \
--cc=colpatch@us.ibm.com \
--cc=hch@infradead.org \
--cc=jbarnes@sgi.com \
--cc=joe.korty@ccur.com \
--cc=linux-kernel@vger.kernel.org \
--cc=manfred@colorfullife.com \
--cc=mikpe@csd.uu.se \
--cc=pj@sgi.com \
--cc=rusty@rustcorp.com.au \
--cc=wli@holomorphy.com \
/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.