Messages in this thread | | | Date | Mon, 22 Mar 2004 18:09:40 -0800 | From | William Lee Irwin III <> | Subject | Re: [PATCH] Introduce nodemask_t ADT [0/7] |
| |
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |