[lkml]   [2004]   [Apr]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] mask ADT: new mask.h file [2/22]
On Mon, 2004-04-05 at 17:05, Paul Jackson wrote:
> P.S. - Perhaps you real concern here is that I'm not going far enough.
> Instead of just putting the cpumask_t internals on a diet
> and allowing for a nodemask_t that shares implementation,
> rather I should change both outright, to the more explicit
> style that is perhaps what you have in mind:
> struct cpumap { DECLARE_BITMAP(bits, NR_CPUS); };
> struct cpumask s, d1, d2;
> bitmap_or(s.bits, d1.bits, d2.bits);
> Nuke cpumask_t, nodemask_t and the existing cpus_or,
> nodes_or, ... and similar such 60 odd various macros
> specific to these two types.
> I rather like that approach. It would build nicely on
> what I've done so far. It would be a more intrusive patch,
> changing all declarations and operations on cpumasks.

Yes, this is exactly the point I was incoherently groping towards.
Throw away mask.h, and make any needed enhancements to bitmap.h (eg.
inlines which check for the case of len <= BITS_PER_LONG).

Then change cpumask_t and nodemask_t ops to inlines which just use
bitmap.h, and get rid of the
asm-generic/cpumask_optimized_for_large_smp_with_sparse_array_and_small_stack.h etc. and then finally look at how ugly it would be to change users to directly using the bitmap.h functions on cpumasks.

> If I thought it would sell, I would be most interested.

I guess I'd like to see the cost of perfection. It could just be that
the current cpumask_t headers creep me out...

Anyone who quotes me in their signature is an idiot -- Rusty Russell

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 14:02    [W:0.065 / U:3.164 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site