With the latest snapshots on my web-page I have tried to implement a
somewhat sane(?) support for persistent storage for modules.
(I'm up to modules-1.3.69j by now.)
Here are the basics:
- A module can call "set_persist("a key", &value, sizeof(value))"
to save whatever information it wants about its state.
This includes arrays or structs or whatever.
- The best place to put this (these) call is in "cleanup_module()",
but it can be called anywhere (and multiple times) in the module.
- The value will be stored inside kerneld via the key, and also
in a gdbm file (in /lib/modules/`uname -r`/persist.gdbm).
- The value for any key can be restored by a call to
"get_persist("a key", &value, sizeof(value), probably
best in "init_module()".
- An even better way is to allow insmod to handle insertions
of persistent data:
insmod module.o symbol=?'a key':default_value
^ ^
Markers
(The quotes are there only to protect the space in the key.)
Example:
insmod 3c509 irq=?3c509.1.irq:10
where "3c509.1.irq" is the key that the module used
when it called "set_persist" with the irq for the
first 3c509.
If no key with that name is found, the default value 10 is used.
Without any default value(s), no updates will be made to the
module symbol.
- Since all persistent data is saved in a gdbm file, it will
survive re-boots.
- Kerneld reads the gdbm file when it start, and when it receives
a "kill -1".
- A trivial utility (admpersist) in the latest snapshot can be used
to modify the contents of the gdbm file (for integers at least).
With this utility called from your rc.d you can remove those
persistent keys that should be probed "fresh" after a reboot...
admpersist -d key1 key2 key3 ...
I would appreciate comments on this!
I would really like to have everything in place by 2.0!!
(Note that you probably want to keep the gdbm shared library in /lib
if you have /usr on a separate partition :-) )
Cheers,
Bjorn <bj0rn@blox.se> <http://www.pi.se/blox/>