Subject: Re: CVS commit: src
To: None <email@example.com>
From: Anders Magnusson <firstname.lastname@example.org>
Date: 01/25/1999 17:46:03
> On Sun, 24 Jan 1999 19:45:37 +0100 (MET)
> Anders Magnusson <email@example.com> 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.