tech-kern archive
[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index][
Old Index]
Re: Kernel modules
Hi, Andrew
On Jan,Thursday 17 2008, at 12:07 PM, Andrew Doran wrote:
On Wed, Jan 16, 2008 at 12:48:20PM +0000, Andrew Doran wrote:
What needs to happen for it to replace LKMs:
- Conversion of the modules under sys/lkm.
- Linker relocation code for mips, hppa.
- Some changes to improve robustness in a couple of places.
- Locking for kern_ksyms.c
I thought of a few more things this morning:
- We need some new calls for modules to make so that they can link
what
they provide into the system. Currently, kern_lkm.c takes care of
most of
this. One goal was to remove this indirection because it's
complicated and
difficult to understand what is going on. So the new style modules
call
directly into whatever subsystem they interact with to say "I'm
here".
For file systems those calls already exist: vfs_attach() and
vfs_detach().
We need calls like syscall_attach() and so on. Picking sysvshm as an
example, it's entries would never appear in the syscall table at
boot,
even if built into the system. When the module is initialized it
would
enter them.
Some time ago I have changed ddb to accept new command tables from
LKM. I have added two external visible functions [1], db_register_tbl,
db_unregister_tbl. With this interface LKM can add/remove functions to
ddb interface. I can rename them to something more standard ddb_attach/
ddb_detach + I can add test ddb command table to example module, too.
If it is needed. There is no locking for now because I thought that it
is not needed is this still true ?
[1]http://opengrok.netbsd.org/source/xref/sys/ddb/db_command.c#450
[snip]
Regards
Adam.
Home |
Main Index |
Thread Index |
Old Index