Persistent module storage - modutils design
Enough people have asked for persistent module storage to at least justify me writing the code. The design is simple.
MODULE_PARM(var,type) currently defines type as [min[-max]]{b,h,i,l,s}. For persistent data support, type is now [min[-max]]{b,h,i,l,s}{p}, the trailing 'p' for persistent is optional. Existing modutils only checks one character after [min[-max]] so this is backwards compatible, no need to upgrade modutils unless you want persistent data.
insmod takes parameters from modules.conf, from the saved persistent data (see below) and from the command line, in that order. The last value for a parameter takes precedence.
rmmod locates the object for the module using the __insmod_xxx_O ksyms entry. If the object cannot be found or its timestamp has changed since it was loaded then rmmod silently skips the persistent data. Otherwise rmmod uses the .modinfo data in that object to determine the address and type of the persistent parameters. Each persistent parameter is extracted from the module being unloaded, formatted as a module parameter (e.g. "irq=17") and written to /somewhere/module_name which is a text file (vi is the ultimate configuration tool).
Almost all support is in user space. The only kernel change is to add 'p' to the end of module parameters that are to be persistent. Module variables that are to be persistent and are not currently module parameters need to be defined as MODULE_PARM(). The same kernel code should work on 2.2 and 2.4 kernels, it should even work with modutils 2.1.121.
I have not decided where to save the persistent module parameters. It could be under /lib/modules/<version>/persist or it could be under /var/log or /var/run. I am tending towards /var/run/module_persist, in any case it will be a modules.conf parameter.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
Quoted 3 lines · Keith Owens
insmod takes parameters from modules.conf, from the saved persistent data (see below) and from the command line, in that order. The last value for a parameter takes precedence.
Correction: modprobe takes parameters from ...
insmod only does exactly what you tell it to. It does not get parameter values from modules.conf or anywhere else, only from the command line.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
Keith Owens <[email protected]> said:
[...]
Quoted 4 lines
I have not decided where to save the persistent module parameters. It could be under /lib/modules/<version>/persist or it could be under
/var/logor/var/run. I am tending towards/var/run/module_persist, in any case it will be a modules.conf parameter.
/var/lib/persist/<version>/<wherever-the-module-is-in-/lib/modules/<version>/>
or some such. It has to match the kernel version somewhere (in case module interfaces change), and it also should mirror the tree under /lib/modules/<version> if for no other reason that there might show up several modules named <foo>.
Signature · 8 lines
Dr. Horst H. von Brand mailto:[email protected] Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] Please read the FAQ at http://www.tux.org/lkml/
Horst von Brand <[email protected]> said:
[Yes, I know this is bad taste...]
Quoted 9 lines
Keith Owens <[email protected]> said:
[...]
Quoted 4 lines
I have not decided where to save the persistent module parameters. It could be under /lib/modules/<version>/persist or it could be under
/var/logor/var/run. I am tending towards/var/run/module_persist, in any case it will be a modules.conf parameter.
Quoted 6 lines
/var/lib/persist/<version>/<wherever-the-module-is-in-/lib/modules/<version>/>
or some such. It has to match the kernel version somewhere (in case module interfaces change), and it also should mirror the tree under /lib/modules/<version> if for no other reason that there might show up several modules named <foo>.
Note! This _has_ to be in the / filesystem so it works before mounting the rest of the stuff (if ever). This would rule out /var, and leave just /lib/modules/<version>. Makes me quite unhappy...
Signature · 8 lines
Dr. Horst H. von Brand mailto:[email protected] Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] Please read the FAQ at http://www.tux.org/lkml/
Quoted 9 lines · Horst von Brand
Quoted 5 lines
Quoted 4 lines · Keith Owens
I have not decided where to save the persistent module parameters. It could be under /lib/modules/<version>/persist or it could be under
/var/logor/var/run. I am tending towards/var/run/module_persist, in any case it will be a modules.conf parameter.Note! This _has_ to be in the / filesystem so it works before mounting the rest of the stuff (if ever). This would rule out /var, and leave just /lib/modules/<version>. Makes me quite unhappy...
Modules are loaded before non-root file systems are mounted, damn! Looks like persistent data has to be stored in /lib/modules/persist (no <version>, see earlier mail). If somebody wants both a read only /lib and persistent data then /lib/modules/persist must be a symlink and they must mount the target file system before loading modules with persistent data.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
In message <[email protected]> you write:
Quoted 7 lines
Quoted 3 lines · Horst von Brand
Note! This _has_ to be in the / filesystem so it works before mounting the rest of the stuff (if ever). This would rule out /var, and leave just /lib/modules/<version>. Makes me quite unhappy...
Modules are loaded before non-root file systems are mounted, damn!
modules.conf already breaks FHS lib/ badly enough. Modules loaded before /var is mounted won't get persistant data. Too bad; they have to do something sane when it doesn't exist anyway.
Quoted 2 lines
Looks like persistent data has to be stored in
/lib/modules/persist(no <version>, see earlier mail).
You need versions: binary data is too prone to change (proven kernel history). It's the kernel installer's duty to know which ones can be safely linked/copied to the new version.
Otherwise every data change requires a new symbol name: and this will happen all the time.
Rusty.
--
Hacking time.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
Quoted 7 lines · Rusty Russell
In message <[email protected]> you write:
Quoted 2 lines
Looks like persistent data has to be stored in
/lib/modules/persist(no <version>, see earlier mail).You need versions: binary data is too prone to change (proven kernel history). It's the kernel installer's duty to know which ones can be safely linked/copied to the new version.
Not saving persistent data in binary format, so no problem.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
Followup to: <[email protected]> By author: Rusty Russell <[email protected]> In newsgroup: linux.dev.kernel
Quoted 7 lines
Quoted 2 lines
Modules are loaded before non-root file systems are mounted, damn!
modules.conf already breaks FHS
lib/badly enough. Modules loaded before /var is mounted won't get persistant data. Too bad; they have to do something sane when it doesn't exist anyway.
Last I checked modules.conf was in /etc, not in /lib.
Quoted 11 lines
Quoted 3 lines
Looks like persistent data has to be stored in
/lib/modules/persist(no <version>, see earlier mail).You need versions: binary data is too prone to change (proven kernel history). It's the kernel installer's duty to know which ones can be safely linked/copied to the new version.
Otherwise every data change requires a new symbol name: and this will happen all the time.
Remember that we cannot rely on ANY form of persistent storage to be available in the beginning; / may very well be readonly (on a ROM, say.) Since that means that we can't rely on writable storage being available until at least one other filesystem has been mounted, it might as well be the standard for variable data, i.e. /var.
-hpa
Signature · 7 lines
<[email protected]> at work, <[email protected]> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] Please read the FAQ at http://www.tux.org/lkml/
Quoted 5 lines · H. Peter Anvin
Remember that we cannot rely on ANY form of persistent storage to be available in the beginning; / may very well be readonly (on a ROM, say.) Since that means that we can't rely on writable storage being available until at least one other filesystem has been mounted, it might as well be the standard for variable data, i.e. /var.
Agreed. Default is /var/lib/modules-persist. People who have a separate /var partition that is mounted after modules are loaded can use / and specify
persist /lib/modules/persist
in /etc/modules.conf. If you have a separate /var and you do not want to write to /, change your initialization scripts to load modules after mounting /var.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
Quoted 3 lines
Note! This _has_ to be in the / filesystem so it works before mounting the rest of the stuff (if ever). This would rule out /var, and leave just /lib/modules/<version>. Makes me quite unhappy...
The /lib filesystem is likely not writable so /var is the right default. Any reason it cant be overridden in modules.conf ?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
Quoted 5 lines · Alan Cox
Quoted 3 lines
Note! This _has_ to be in the / filesystem so it works before mounting the rest of the stuff (if ever). This would rule out /var, and leave just /lib/modules/<version>. Makes me quite unhappy...
The /lib filesystem is likely not writable so /var is the right default.
In theory yes. In practice /var is often a mounted filesyste so for modules loaded before /var is mounted this solution gets somewhat ugly.
Ralf
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
Quoted 10 lines · Horst von Brand
Quoted 4 lines · Keith Owens
I have not decided where to save the persistent module parameters. It could be under /lib/modules/<version>/persist or it could be under
/var/logor/var/run. I am tending towards/var/run/module_persist, in any case it will be a modules.conf parameter./var/lib/persist/<version>/<wherever-the-module-is-in-/lib/modules/<version>/>
or some such. It has to match the kernel version somewhere (in case module interfaces change),
But then you get the problem that upgrading from one kernel release to the next loses the persistent data; either option has potential problems. I am tending towards no version number and have a flag on insmod that says "the following parameters may not exist in the module, be silent about any unknown symbols", the flag is automatically set by modprobe for persistent parameters.
Going forward is not a problem, going backwards silently ignores unknown parameters.
Quoted 3 lines
and it also should mirror the tree under /lib/modules/<version> if for no other reason that there might show up several modules named <foo>.
It makes no sense to allow duplicate module names in the same kernel tree. "modprobe foo" - which one gets loaded?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
Keith Owens <[email protected]> said:
[...]
Quoted 2 lines
It makes no sense to allow duplicate module names in the same kernel tree. "modprobe foo" - which one gets loaded?
Why the tree then?
Signature · 8 lines
Dr. Horst H. von Brand mailto:[email protected] Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] Please read the FAQ at http://www.tux.org/lkml/
Quoted 5 lines · Horst von Brand
Quoted 2 lines · Keith Owens
It makes no sense to allow duplicate module names in the same kernel tree. "modprobe foo" - which one gets loaded?
Why the tree then?
Mainly so you can "modprobe -t net \*" and load all modules with /net/ in their pathname. pcmcia modules need to be identified and linked. mkinitrd also needs paths to identify scsi modules. The old system of assigning pathnames was manual, fragile and error prone, copying the kernel tree works. But whether modules are a flat directory, a manually built two level directory or a copy of the kernel tree, it still makes no sense to have duplicate names in the same kernel tree.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/