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.

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

And, at least in the case of ELF, the code that registers all of the LKM's
goo (VFS entry, syscall entry, etc.) could be handled by global contructors.
The ungregister stuff could be handled by global destructors.  A nice generic
mechanism for dealing with it all, IMO.  No need for a modload _at all_.

Usrland could explicitly load a module by executing a system call like:

struct lkm_load_args {
	const char *path;
} args;

	args.path = "/usr/lkm/misc/ipfilter.so"

	lkmctl(LKM_LOAD, &args);

...when the kernel's dynamic linker finishes mapping the module and dealing
with the symbols, then it simply invokes all of the __CTORS__[], the last one
of which would handle the LKM's registration goo.  (Careful readers will note
that this would allow modules written in C++ to be used, as well.)

When the kernel gets ready to unload the module (either explicity upon
an lkmctl(LKM_UNLOAD, ...) or implicity by e.g. last reference of the
file system going away), it can call the __DTORS__[], the last one of which
would unregister all the things registers by the contructors.

So, in my world, you go to mount a file sytem, e.g. cd9660.

	- mount syscall finds no "cd9660" in the VFS list.

	- mount calls internal LKM code to search for "vfs/cd9660.so".

	- internal LKM code scans for "vfs/cd9660.so", prepending the
	  configured LKM path prefixes one at a time.

	- When cd9660 contructor registrs "cd9660" in the VFS list, it
	  makes a note that the file system was dynamically loaded.

	- If module is loaded successfully, mount syscall attempts to mount
	  again.

...now you unount the last instance of "cd9660":

	- 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? :-)

 > - /dev/ksyms, to be able to access an up-to-date symbol table. (as a side
 >   effect ps stopped to care about from which kernel the system was loaded :-)

This is pretty cool :-)

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

        -- Jason R. Thorpe <thorpej@nas.nasa.gov>