Persistent Storage Across Unload/Load
Once we’ve equipped ourselves
with kerneld and version support, using modules
turns out to be more flexible than using linked-in drivers. There’s
only one argument against modularization: if a driver is loaded by
kerneld and then configured (via ioctl or other means), it
must be reconfigured the next time it is loaded into the
kernel. While load-time configuration can be specified once and for all in
/etc/modules.conf
, run-time configuration becomes volatile when
demand loading is heavily used. The user can be disappointed by
finding that device configuration has been lost after a coffee break. What we
need is a technique for persistently storing relevant information while
the module is unloaded.
In fact, the modules package offers this kind of
capability starting with version 2.0.0 (modules-2.0.0
).
The actual code has not yet been integrated into the official
kernels, but it is likely it will be accepted in Linus’ sources.
Currently, to
enable support for persistent storage, you need to apply a patch that
is distributed in the modules package; the patch adds a
few lines to <linux/kerneld.h>
.
In practice, the idea behind persistent storage of module information is straightforward: kernel code can use the same kerneld engine that loads and unloads modules to transfer information to and from user space. The daemon then uses a general-purpose database to manage information storage.
The reason for implementing persistent storage in user space ...
Get Linux Device Drivers now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.