Hello, On 12/08/2009 05:24 PM, Ingo Molnar wrote: >> Acked-by: Frederic Weisbecker <fweisbec@xxxxxxxxx> > > I have applied it - but really, the new percpu namespace changes headed > towards upstream are quite a nuisance IMO. The 3-4 (trivial to solve) > breakages i've seen so far affecting code i maintain give us an > estimation about the ongoing maintainence cost - which wont be high but > not zero either. > > The change that was forced here: > > -static DEFINE_PER_CPU(unsigned int, task_bp_pinned[HBP_NUM]); > +static DEFINE_PER_CPU(unsigned int, nr_task_bp_pinned[HBP_NUM]); > > Is it really an improvement to the old code? > > Dunno. In each specific conflict, I don't think it would be an apparent improvement but overall I do believe it's headed the right way. Well, or, at the very least, I don't see any other viable solution and you're probably the most strongly affected by the change. Sorry about the inconveniences. I'm waiting for ack for a m68k change before pushing out percpu tree. I'm not completely determined but I think I'll keep dropping per_cpu__ prefix and sparse annotation in linux-next for one more cycle as sparse annotation cleanup pass hasn't been done yet. Once new devel cycle begins, it might be a good idea to pull in percpu changes into one of the tip trees so that these nuisances can be detected during development? Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-next" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
