An idea: a database of modules settings

Eyal Lebedinsky (eyal@fir.canberra.edu.au)
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?