Messages in this thread | | | Subject | Re: lib.a causing modules not to load | From | James Bottomley <> | Date | 08 Nov 2003 09:16:10 -0600 |
| |
On Sat, 2003-11-08 at 02:51, Christoph Hellwig wrote: > On Fri, Nov 07, 2003 at 08:34:19PM -0800, Andrew Morton wrote: > > How about we just link that function into the kernel and be done with it? > > We'll waste a few bytes on SMP machines which have neither ext2 nor ext3 > > linked-in or loaded as modules, but that doesn't sound very important... > > > > (We don't have a kernel/random-support-stuff.c, but we have > > mm/random-support-stuff.c which for some reason is called mm/swap.c, so > > I put it there). > > Well, this solves the problem for this particular case, but not other > stuff in lib for other situations.
I agree...there's much more in lib than just percpu_counter_mod.
> We should just stop building lib > as archive and conditionalize building bigger and rarely used stuff in > there using Kconfig symbols.
Actually, I do think lib serves a purpose for shared routines that are used in disparate places throughout the kernel.
Why code these as Kconfig symbol dependencies when the library mechanism does exactly what we want except for this one all symbols are in modules case. As a counter example: kobject is in lib...Imagine exactly how many Kconfig conditions we'd have to introduce to conditionalise that...
I really think the correct way forwards is to fix the one failing case; I was just asking if anyone had already thought about it.
James
- 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/
| |