Subject: Re: CVS commit: src
To: Herb Peyerl <>
From: Anders Magnusson <>
List: tech-kern
Date: 01/24/1999 19:45:37
> [Moved to tech-kern and Bcc'd to source-changes for continuity]
>  wrote:
>  > said:
>  > > Modified Files:
>  > > 	src/sbin/modload: modload.8 modload.c
>  > > Log Message: Allow modload to load symbols for use by DDB. 
>  > 
>  > I'm somehow hesitating to throw this into NetBSD's modload
>  > just now because the LKM interface sucks at different places
>  > that much that I don't even like to look at it...
>  > cgd came up with ideas for a ld_so like scheme quite a
>  > while ago (FreeBSD got it in the meantime), and I was
>  > hoping that someone experienced in toolchain issues takes
>  > a stab on it sooner or later.
> You might wish to speak with ragge... he and some others have
> done some work in this area.
> Ragge?
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
  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.
  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