Re: [PATCH] cpumask 5/10 rewrite cpumask.h - single bitmap basedimplementation
From: Nick Piggin
Date: Fri Jun 04 2004 - 00:40:10 EST
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 :)
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/