Excerpts from netbsd: 12-Aug-96 Re: LKM support for many fi.. Michael
Graff@flame.org (1183)

> Guenther Grau <s_grau@ira.uka.de> writes:
> 
> > I remember the you presented this extended interface, but I cannot
> > remember any discussion about it.

> I didn't see it posted originally.  Mail me the message?

Unfortunately, I can't find a copy. Either I didn't keep one or I
lost it during a power failure with slight filesystem damage last week.

As I mentioned, the key idea is to have an array of these LKM definition
structures instead of just one of them.
For sanity, I rearranged the structure elements a bit to separate
per-function and per-module variables. Some DDB symbol table
support is included too.

[other solutions]

The FreeBSD people have some LKM's which contain more then one
function. They do it by overloading the private portion of the lkm
structure between the calls to lkmdispatch() (one call per function).
This is ugly for me. There is no reference count or whatever dependency
handling, like in NetBSD.

Linux does a complete symbol table management inside the kernel.
Dependencies are handled, obviously by counting the references
to symbols. (Don't know whether more inplicite dependencies -
via pointers - are handled too.)

I personally would prefer a solution outside the kernel, for principal
reasons.
Even now, it is possible to stack lkms on another one - give the output
of the first load as "-A" to the second. This won't work for more complex
topologies, but should be sufficient for most people.
I this nlist stuff was not so crufty... one could easily manage the symbol
table with a small utility (and perhaps keep a symlink /netbsd to the
current symbol table).
Dependencies should be handled by more function-specific code,
otherwise I'd worry about hidden cross-connects and/or memory
leaks.

> So, who here is interested in researching these things and helping with
> a new spec?

I certainly have much more absurd ideas than time to implement them.
But, if there is something I can help with, I'll do it.

best regards
Matthias Drochner