Messages in this thread |  | | From | (Eyal Lebedinsky) | Subject | An idea: a database of modules settings | Date | Sun, 5 May 1996 19:41:02 +1000 (EST) |
| |
Hello everyone,
The following suggestion will certainly miss 1.4/2.0 but it is urgently needed. It is high time we address this problem.
Those of us who use loadable modules (either using kerneld or not) would have already noticed how soft settings get lost when a module is unloaded. The current solution is to use things like 'before unload' and 'after load' in the conf file to save/restore the settings. This means too much manual intevention.
For example, I recently had a problem where the scsi-tape (st) module was reloaded half way through mu backup script which uses afio to back up a dozen partitions to files on a DAT tape. This reload caused the driver to lose it's settings, especialy the SCSI2-LOGICAL location feature which is critical to my creating a useful log from the run. I had to do the load/unload manualy in the script to gurantee it stays put. This is not something I should worry about and it may fail other systems that access a feature intermittently without repeating a full configuration process.
How about a standard API where a module can save/restore any number of settings between sessions. The module will simply call somethings like save_settings (int id, void *buffer, in size) where the id allows a module to save multiple buffers. The info will be saved and later the module (when loaded) can request the settings with a similar 'get_settings' call.
I believe that we must present a stable model for a module, regardless of it being static, dynamic or kerneld controlled; this is not the case now. The above feature will allow this to be implemented.
While one can see this as a kerneld service, it may be better to allow manualy un/loaded modules to use it.
Introducing this facility can be done gradualy: when the service is available it is up to each module to save/restore the appropriate settings.
BTW, in the current solution (conf based before/after processes) is it al all guaranteed that the 'after load' will complete before the freshly loaded module gets used?
Then again, maybe anybody is already doing something about this?
|  |