> Excerpts from netbsd: 15-Sep-97 Re: Handling multiple lkm's matthew
> green@eterna.com (433)
> 
> > infact, there is a patch from jtkohl in the PR databsae that
> > fixes this for a.out systems, that i plan on commiting soon.
> 
> You didn't tell the PR number, so I guess you are referring to
> PR 791 "modload doesn't load a.out symbols".
> This doesn't solve not the problem I meant in my original
> mail - that the (user space) symbol table which is used to
> link new LKMs against is not updated.

On the other hand, I'd say that it's a larger problem that LKMs are
handled the way that they are, in general.

The use of user-land 'ld' causes a whole host of problems (symbol
table lossage when adding modules after other modules, requirement
that you have an initial symbol table around at all, need for 'ld'
(which implies need for /usr), etc.

In my opinion, the 'right' thing to do is make all shared libs
effectively be dynamically loadable objects, in the dlopen()/.so
sense.  Then load them, and have a small dynamic linker in the kernel
(only #ifdef LKM!) which does the right things.

That solves the symbol table problems (you can either use a loaded
kernel symbol table, or, better, define a specific set of symbols to
be exported to modules, and _only_ the the modules use those symbols),
it solves the need for ld, and it shouldn't eat very much space (and
that conditional on the LKM option being included in the kernel).  It
also leaves the door open for future 'interesting' work, e.g. signed
LKMs which can be verified by the kernel, etc.


cgd