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.