Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Wed, 19 Feb 2003 19:25:38 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Wed, 19 Feb 2003 19:25:37 -0500 Received: from dp.samba.org ([66.70.73.150]:62374 "EHLO lists.samba.org") by vger.kernel.org with ESMTP id ; Wed, 19 Feb 2003 19:25:35 -0500 From: Rusty Russell To: Mikael Pettersson Cc: linux-kernel@vger.kernel.org Subject: Re: module changes In-reply-to: Your message of "Wed, 19 Feb 2003 13:52:55 BST." <15955.32295.830237.912@gargle.gargle.HOWL> Date: Thu, 20 Feb 2003 11:15:25 +1100 Message-Id: <20030220003539.E12F92C311@lists.samba.org> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1344 Lines: 31 In message <15955.32295.830237.912@gargle.gargle.HOWL> you write: > Rusty Russell writes: > > The problem is that then you have to have to know whether this is a > > per-cpu thing created in a module, or not, when you use it 8( > > Ah yes. I totally missed that. (Shakes head in disbelief.) It's an easy thing to miss. > > I agree with you (and John) about disliking the limitation, but is it > > worse than the current no per-cpu stuff in modules at all? > > In my case (perfctr driver) it means not being able to use per-cpu > stuff at all since I need to be able to build it modular. Or I have > to hide per_cpu() behind private macros that fall back to an [NR_CPUS] > implementation in the modular case. I can live with that. Well, there's kmalloc_percpu() there already. But perfctr certainly won't hit the "more per-cpu data than the core kernel" case, from my brief reading of the code. If something does, then the core kernel minimum can be increased (which is a little hacky, but hey). Thanks, Rusty. -- Anyone who quotes me in their sig is an idiot. -- Rusty Russell. - 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/