>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.

This is considered ugly by the FreeBSD people as well.  The last time
it was discussed, a kernel symbol table management scheme was proposed,
but I think this has been tabled until someone finds the time to really
look into it and do something about it.  Assuming you can load the
symbols and the code to do symbol table management only while manipulating
LKMs, I think this is the cleanest approach.

>I personally would prefer a solution outside the kernel, for principal
>reasons.

What are these 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.

This doesn't sound very pretty.

>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.

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.  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 was one of the motivating forces behind some
discussion in that past about moving FreeBSD to an ELF kernel.

>best regards
>Matthias Drochner

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