Subject: Re: lkm improvements ...
To: Anders Magnusson <firstname.lastname@example.org>
From: Robert V. Baron <email@example.com>
Date: 01/24/1999 15:23:29
Anders Magnusson <firstname.lastname@example.org> writes:
> Ok: I sent a poll to Herb a couple of days ago about this, and he
> recommended me to send a note about it to tech-kern to get some
> feedback. I have planned to write a more extensive description of
> what we have, but I haven't had time yet. Anyway, here's essentially
> what this is about:
> We have at the company where I work changed the whole LKM system in NetBSD
> to make it possible to work with a module-based OS. Much of this work
> can be used in NetBSD and I have convinced the board to release it to
> the NetBSD project, since it contains no intellectual property for us.
> Anyway, it's a lots of changes, here's a few of them:
> - 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).
> - 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
Does this mean that you need to still know the name of the kernel that
was loaded (/netbsd.old vs /netbsd). Either the loader needs to be
in the kernel and/or have access to all (or some [the exportable]) symbols
of the kernel.
> many modules). Also, modload loads the symbol table into the kernel.
> - /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 :-)
> - Bdevsw/cdevsw is gone, instead there is a devsw handler to which
> device modules are registered/unregistered.
There is an interesting issue here. The old lkm scheme required that
a module either a dev or a vfs or a single system call. A much better
design would let a module (a linkable unit) register as many and
whatever services it needed to. Coda for example had to abuse the scheme
to be both a device and a vfs.
> Those changes are more-or-less in a (for NetBSD) working state already,
> among what is not done but will be fixed is:
> - Modload understands only a.out for the moment, but ELF support is on the way.
> - The devsw handler will also register devices for a devfs.
> - Modules will get a built-in relation system and revision info.
> This is basically what we have done/planned to do in the future.
> We are using this code in production and will also be maintaining it
> because of that.
> Ok, folks, comments to this?
> -- Ragge