Re: lib.a causing modules not to load

[James Bottomley <James.Bottomley@steeleye.com>]

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