Messages in this thread | | | Date | Wed, 9 May 2012 10:44:53 +0200 | From | Ingo Molnar <> | Subject | Re: [PULL] cpumask: finally make them variable size w/ CPUMASK_OFFSTACK. |
| |
* 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
| |