Hi, Andrew

On Jan,Thursday 17 2008, at 12:07 PM, Andrew Doran wrote:

quoted text
> 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.