>Excerpts from netbsd: 13-Aug-96 Re: LKM support for many fi.. "Justin T.
>Gibbs"@freefa (2036)
>
>[symbol table management for LKMs]
>
>> >I personally would prefer a solution outside the kernel, for principal
>> >reasons.
>> 
>> What are these reasons?
>
>Do only in the kernel what cannot be done outside.
>And: Keep It Simple and Stupid.
>
>> I think that you have to have an LKM manager that knows what LKMs are
>> loaded (or staticly in the kernel) and provides entry points for a loading
>> LKM to request any LKMs it depends on to be loaded.
>
>This can all be done externally - I think of a make-like dependency
>tree, used by the LKM loader.

I believe that performing this work outside of the kernel reduces
robustness and prevents the aplication of KISS.  As an LKM provider, I want
to simply hand you an LKM and have it work for you.  So long as the kernel
you have can understand this version of my LKM, it should, without you
having to muck with some external representation of its dependancies, or
ensuring that you have the proper version of ld, or that you have a
writable filesystem, etc.  I'm also expecting the symbol table manager for
LKMs to be *very* simple and small.  Since LKMs are loaded/unloaded rarely,
it doesn't have to be extremely fast either.

I also want whatever scheme is deviced to allow me to boot and replace/load
a device driver via floppy at boot time and allow for a very small generic
kernel that pulls almost all device drivers from LKMs.  The first feature
makes it simple to ship updated/fixed LKMs without having to roll a full
release just to fix a bogus driver that prevents people from installing
(its also convenient for other reasons). The second feature becomes
excedingly important if you want to provide a single set of installation
media since staticly including all device drivers quickly makes
installation on small memory machines unfeasible.

>> It would also be
>> nice to be able to separate portions of the LKM so that you don't have to
>> load the whole thing in order to determine if the hardware it applies to
>> is in the system.
>
>This sounds nice - even parts of the static kernel could be dropped
>once the system is up...
>If this worked, I would never object against an internal symbol
>table manager again (this is like shared libraries in the kernel).

The LKM manager could not be "dropped", but it could be swapped out.  After
all, I can't have it as an LKM 8-).  I don't know how much work providing
pageable sections of the kernel would be though.  The symbol table could be
extracted and freed by an external utility that allowed you to reload it
into the kernel I suppose.

>best regards
>Matthias Drochner
>

--
Justin T. Gibbs
===========================================
  FreeBSD: Turning PCs into workstations
===========================================