> On Sun, 24 Jan 1999 19:45:37 +0100 (MET) 
>  Anders Magnusson <ragge@ludd.luth.se> wrote:
> 
>  > - The symbol table handler (from DDB) is fixed to support the symtab from
>  >   LKM's also. (Needed to have modules loaded on modules, and to get DDB
>  >   to work on modules).
> 
> Cool cool...  Perhaps this can be generalized into "kernel symbol handling",
> which both the LKM code and DDB code are clients of?  See below.
Already done. That was one of the points :-)

> 
>  > - Modload has got its own linker (no need for gld), and it has some small
>  >   tricks to not page-align modules (saves LOTS of memory when there are
>  >   many modules). Also, modload loads the symbol table into the kernel.
> 
> Since you're implemented your own linker :-) :-), this could (and should)
> be put into the kernel.  The idea here is that then the kernel could, on its
> own, search out and load modules (e.g. file systems, device drivers, etc.)
> based on name.
> 
This is a cool idea, but may cause some problems. Linking may take some
time, and because the kernel isn't preemptive inside everything would block 
during the link time. 

[...]
> 
> 	- unount system call sees that "cd9660" was a dynamically loaded
> 	  file system, and calls the internal LKM code to unload it.
> 
> This is all handled in the kernel... there is no hoakey kernel-userland
> protocol to deal with... nice, clean, simple.
> 
> Am I making any sense? :-)
> 
This would actually be rather nice. It may be a good idea to check out
how this would work in reality. 

> 
>  > - Bdevsw/cdevsw is gone, instead there is a devsw handler to which
>    device modules are registered/unregistered.
> 
> ..okay.  There needs to be a way for userland to query LKMs about e.g.
> which system call number they got, which c/b major they got, etc.  Some
> sort of generic "dynamic attributes" query mechanism.
> 
That is an issue, yes.

-- Ragge