Re: [PATCH] Introduce nodemask_t ADT [0/7]

[William Lee Irwin III]

On Mon, Mar 22, 2004 at 05:12:43PM -0800, Paul Jackson wrote:
> I'm not trying to get on your case, Bill, for not creating and applying
> more various cpumask functions.  Rather I am looking for ways to make
> that API easier for others to use and use well.  If the situations that
> passed about temporary cpumasks can be collapsed into single calls that
> are more efficient, then that is one way to make progress on this.
> Taking masks to be a struct of an array of unsigned longs seems to come
> pretty close.  The sparc64 arch would want to pass a pointer to this
> apparently, rather than the struct itself - faster for them. Some other
> smaller archs would _not_ want to pass a pointer, but rather the (one
> word, for them) value - avoids a dereference for them.  In arch specific
> code, each arch can choose which way works best for them.  I need to
> identify any generic code where these preferences collide.

I generally like the idea of the arches getting their choice here (heck,
even wrt. representation; e.g. some arch might want an array of cpuid
numbers and not a bitmap at all due to extremely sparse cpuid's or some
such nonsense). The asm-generic stuff was largely a question of
reducing diffsize, preemptive code consolidation, etc.

I don't believe normal C (i.e. sans typedef) will allow needed
ambiguities that make UP/small SMP/etc. compile things out nicely, but
if you can get the requirement of the stuff totally compiling out
dropped or do it in normal C somehow, go for it. I'd call it a cleanup.


-- wli
-
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/