Messages in this thread |  | | From | Mikael Pettersson <> | Date | Tue, 18 Feb 2003 16:56:11 +0100 | Subject | Re: module changes |
| |
Rusty Russell writes: > In message <20030217213221.3103.qmail@eklektix.com> you write: > > I had a quick question: is the inability to declare per-CPU variables in > > modules going to be permanent? > > <sigh> > > I'd really like to fix it, but that's *hard*. > > <think think think, ask Paulus> > > There might be a neater way, and there's definitely a more > space-efficient way, but this is a start (the wastage is small as long > as there are only a few per-cpu vars, as there are at the moment). > > Rusty. > -- > Anyone who quotes me in their sig is an idiot. -- Rusty Russell. > > Name: per-cpu support inside modules > Author: Rusty Russell > Status: Tested on 2.5.62 > > D: This adds percpu support for modules. A module cannot have more > D: percpu data than the base kernel does (on my kernel 5636 bytes).
This limitation is quite horrible.
Does the implementation have to be perfect? The per_cpu API can easily be simulated using good old NR_CPUS arrays:
#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,5,8) && !defined(MODULE) #include <linux/percpu.h> /* why doesn't this work for modules? */ #else /* Simulate per_cpu() for older kernels or modular builds. */ #define DEFINE_PER_CPU(type, name) \ __typeof__(type) name[NR_CPUS] __cacheline_aligned #define per_cpu(var, cpu) ((var)[(cpu)]) #endif
Yes it wastes space. Big deal. Rather that than arbitrary limitations.
/Mikael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |