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