Excerpts from netbsd: 16-Mar-97 Re: loading lkm's Iain
Hibbert@skate.demon (1685*)

> that might be a nice thing to have in the source tree, as an example of a
> device driver lkm?

There are a lot of problems with lkm's in general and loadable
device drivers in particular which make me consider this
usable for people who "know what they are doing" only.
What comes to mind:
-The kernel lacks modularity at some places, there are
  "#ifdef"s scattered in the code which prevent lkm's from
  working. (example: union fs)
  (This is not really a call for changes - I would never trade in
   stability or efficiency for this.)
-Cross-dependencies - a lkm author con't know if a subsystem
   his module depends on is already in the kernel. For example:
   A loadable driver for if_le_pci depends on am7990.c. If there
   is already a if_le_isa driver in the kernel, this is present,
   otherwise not.
  One could make a separate module of am7990.c. But thes he
  runs into the problem that the current kernel symbol table
  must be known, and that this dependency must be managed
  somehow to prevent am7990 from being unloaded while
  if_le_pci is used.
-Unloading requires that there are no pointers to the module
  are left. Some ressources are not managed in a way which
  makes this easy. example: network addresses
-Unloading is unsave in general, at least for some types of
  lkm's. For instance, a devsw entry can be removed while
  the device is open. (Same for loading, if an existing devsw
  entry is replaced.) The whole system is simply not designed
  with lkm's in mind, and adding this now would require
  redesigns at many places, or it would stay a hack.

Loadable modules are great as long as you avoid these pitfalls
or work around them. 

> it hasn't helped that there are no lkm devices in the NetBSD tree
> (I found one in OpenBSD, and a couple in FreeBSD).

I just had a look at it, and didn't find a driver lkm in OpenBSD.
The FreeBSD lkm's seem to require specially prepared device
drivers, which makes it a bit limited and probably causes
some code multiplication.
The NetBSD autoconfiguration framework usually forgets
the information needed for device probing and initialization
(the "xxx_attach_args") after use, so there it needs some
changes in bus drivers to have them available for later driver loading.
That's the main complication, as far as loading is concerned.
Unloading is more or less a problem of ressource deallocation.

[panics]
> I'm half convinced that its the union filesystem though

>From my experience, the union fs works if you don't touch
the directory where you mounted from. Otherwise, you
get these "locking against myself" panics.
Is this what you see?

> is it possible you could send me a tarfile of
> your framework?

I'll put together the necesarry pieces and put it to a ftp
server (zelof1.zel.kfa-juelich.de:/pub/NetBSD) later.

best regards
Matthias Drochner