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

[Ingo Molnar <mingo@kernel.org>]

* Rusty Russell <rusty@rustcorp.com.au> 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@rustcorp.com.au>
> 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
>     CONFIG_CPUMASK_OFFSTACK is set:
>     
>     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@rustcorp.com.au>
>     Cc: Arnd Bergmann <arnd@arndb.de>
>     Cc: anton@samba.org
>     Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
>     Cc: Mike Travis <travis@sgi.com>

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.

Thanks,

	Ingo