Re: [PULL] cpumask: finally make them variable size w/CPUMASK_OFFSTACK.

From: Ingo Molnar
Date: Wed May 09 2012 - 04:45:10 EST

* Rusty Russell <rusty@xxxxxxxxxxxxxxx> wrote:

> Hi Ingo,
> I finally rebased this on top of your tip tree, and tested it
> locally. Some more old-style cpumask usages have crept in, but it's a
> fairly simple series.

Cool! Most of it looks pretty sane. I have a question about the
gist of the series:

> commit 898eb73305e2277be91b931c5a75484f8c87ae36
> Author: Rusty Russell <rusty@xxxxxxxxxxxxxxx>
> Date: Wed May 9 15:01:15 2012 +0930
> cpumask: remove struct cpumask definition when CONFIG_CPUMASK_OFFSTACK=y
> We're about to change CONFIG_CPUMASK_OFFSTACK so it only allocate
> nr_cpu_ids bits for all cpumasks. We need to make sure that when
> 1) Noone uses the old bitmap ops, which use NR_CPUS bits (use cpumask_*)
> 2) Noone uses assignment of struct cpumask (use cpumask_copy)
> 3) Noone passes a struct cpumask (pass a pointer)
> 4) Noone declares them on the stack (use cpumask_var_t)
> So we finally remove the definition of struct cpumask when
> CONFIG_CPUMASK_OFFSTACK=y. This means that these usages will hit a compile
> error the moment that config option is turned on.
> Note that it also means you can't declare a static cpumask. You
> should avoid this anyway (use cpumask_var_t), but there's a
> deliberately-ugly workaround for special cases, using DECLARE_BITMAP()
> and to_cpumask().
> Signed-off-by: Rusty Russell <rusty@xxxxxxxxxxxxxxx>
> Cc: Arnd Bergmann <arnd@xxxxxxxx>
> Cc: anton@xxxxxxxxx
> Cc: KOSAKI Motohiro <kosaki.motohiro@xxxxxxxxxxxxxx>
> Cc: Mike Travis <travis@xxxxxxx>

Is there any good reason to not remove it altogether, regardless
of whether the OFFSTACK config is set? I mean, triggering build
failures for a relatively rarely turned on config option is
asking for constant maintenance trouble.


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