Excerpts from netbsd: 17-Mar-97 Re: loading lkm's Michael Graff@flame.org (736)

> The filesystems are there and should work, with the possible exception of
> the union fs.

The union fs does definitely not work because there is some code
in vfs_syscalls.c in #ifdef UNION.
OpenBSD has a function pointer there. Not really nice because
one can't have different union-like filesystems (perhaps with
different features) if he wants, but it seems to work.

> I still think there should be some sort of "module registration" interface
> so modload can check to see if the required modules are loaded or not

I think this case is handled by the different LKM loaders (lkmexists()).
There is a design flaw - the user's load function was already called
when the LKM framework decides that the module is already
present, but this is easy to solve.

> If someone can do the symbol table work so one module can find another,

This _can_ be handled from user space - simply use the -o output
of one modload as -A input for the next.
Here comes the dependency problem again. There could be an
elegant solution if the linker was able to accept more than one
-A argument (have a symbol table for each module, perhaps
as /kernfs file).
Or an external utility could add/subtract symbol tables.
These are some ideas... I wouldn't do too much in the kernel, and
I especially don't like the Linux approach to restrict the exported
symbols.
Because there are many other problems with LKMs anyway I
don't think it's usable for "production systems" now - perhaps with
the exception of modloads while going multiuser. That's why
I didn't even try to implement this luxury stuff.

> I will write up a proposal for the lkm rework.
That's a good idea.

best regards
Matthias Drochner