Messages in this thread | | | Date | Thu, 2 Apr 2009 13:13:41 +0200 | From | Martin Schwidefsky <> | Subject | Re: [GIT RFC] percpu: use dynamic percpu allocator as the default percpu allocator |
| |
On Thu, 2 Apr 2009 11:24:18 +0400 Ivan Kokshaysky <ink@jurassic.park.msu.ru> wrote:
> On the other hand, some tricks with DEFINE_PER_CPU() are indeed possible - > for instance, using weak references we could force the compiler to > generate proper addressing mode. So DEFINE_PER_CPU(int, foo) in module > would expand to something like this: > > extern int per_cpu__foo; > asm(".weakref per_cpu__foo, per_cpu_mod__foo"); > __attribute__((__section__(".data.percpu"))) int per_cpu_mod__foo > > The main problem is that our DEFINE_PER_CPU() macro consists of more > than one definition, so it won't be possible to specify both storage class > and initializer with it. > > If it's acceptable to change the semantics from > > static DEFINE_PER_CPU(int, foo) = 1 > > to > > DEFINE_PER_CPU(static, int, foo) = 1 > > then we're ok. > > Or maybe just add STATIC_DEFINE_PER_CPU_xx() variants?
That is what I'm after as well. Just drop the "static" from the DEFINE_PER_CPU statement found inside modules and it works.
My experiments with the weak and visibility attribute failed because the static storage class specifier together with the attribute either causes a compile error or static just overrides the attribute.
-- blue skies, Martin.
"Reality continues to ruin my life." - Calvin.
| |