On Wed, 12 Jan 2000, Keith Owens wrote:
> Some modules claim to have a need to maintain persistent data in the
> kernel even when the module is unloaded and reloaded. I can see four
> approaches to fixing this problem, there may be others. Note: this
> only applies to kernel data, it says nothing about maintaining external
> data across reboots.
>
> Comments please.
>
> (4) Add a kernel service where a module can register arbitrary data and
> find it again during reload.
> Pro: No changes to Makefiles, modutils, ksymoops.
> Persistent data is only allocated when a module is used at
> least once instead of always compiled into the kernel.
> No unnecessary exports.
Very generic, thus nice. You could create a global hash for the keys
and store a void pointer - ~100 lines of code.
Or you could do a filesystem and export the key/value pairs which
lets ksymoops & friends do a lookup (if necessary) through /dev/kmem.
Its sort of a "simple" database, so you make it the "new sysctl" mechanism
- store a type additional to the void* pointer. And add a syscall
sysctl2.
After all, think about a generic mechanism not only useful for the
persistent module data problem.
> Con: Every module that needs persistent data has to be modified to
> call name_token_xxx() and kmalloc its persistent data.
> ksymoops can not find kmalloc data so it will not be able to
> decode persistent data created using this technique.
No module that needs persistent data does solve the problem ATM - so there
is no point in counting adding new code as con.
Richard.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Jan 15 2000 - 21:00:20 EST