Persistent module storage - modutils design

Quoted 7 lines · Jesse Pollard

Keith Owens <[email protected]>:

Quoted 5 lines

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

Quoted 8 lines

How about including the posibility for some binary data. If something like devfs were to store permanent data, then it would likely contain a list of security labels (rwx/owner/group/(future mac)). This could be a sizable block to store in ascii (but hex might be reasonable).

This would shift the "MODULE_PARM" definition to something like:
MODULE_PARM(var,type,size)
where size is only used when the type would be binary.

#define MAX_PERSIST 100
int mode[MAX_PERSIST];
int owner[MAX_PERSIST];
int group[MAX_PERSIST];
MODULE_PARM(mode, "1-" __MODULE_STRING(MAX_PERSIST) "ip"); MODULE_PARM(owner, "1-" __MODULE_STRING(MAX_PERSIST) "ip"); MODULE_PARM(group, "1-" __MODULE_STRING(MAX_PERSIST) "ip");

Resulting data looks like this, trailing all zero values are removed.

mode=420,420,493
owner=0,0,1
group=0,0,2

No need for a separate size field. Note that MODULE_PARM is built at compile time so all persistent data must have a fixed compile time size.

Pure binary immediately runs into kernel version skew problems. If the data in kernel 2.4.n is

struct { int mode; int owner; int group; } persistent[MAX_PERSIST];

but kernel 2.4.n+1 has

struct { int mode; int owner; int group; long acl; } persistent[MAX_PERSIST];

Then saving binary data from kernel 2.4.n and loading it into 2.4.n+1 or vice versa results in garbage because the structure format has changed. Separating individual fields and treating them as text has no such problem. I have already decided that persistent data will not be passed to insmod on the command line, instead insmod will read directly from the saved data file, that removes any worries about command line limitations.

Quoted 4 lines

This could hold a lot of data, as well as allow for parameters that are configured in user space, but don't take effect until next device load or boot (buffer size settings, kernel scheduling options, memory resource controls...).

If the values are implemented via modules then make them persistent. OTOH if they are implemented via code that is built into the kernel then insmod is far too late.

Quoted 6 lines

An additional option would be an IOCTL (or something)
on the resource file to indicate a userspace update had been made (including the parameter identifier) so that the appropriate driver/module could be requested to perform an update. This would be most usefull for being able to atomicly change kernel parameters (scheduling or resource controls).

Now you are getting into the area of configuration utilities and the interface between such utilities and the kernel as a whole, not just modules. That is a seperate problem and is best left to the configuration tools that already exist. Module persistent data is intended for values in individual modules that the user changes daily or even hourly (volume, TV tuner), not for overall system control.

From: Keith Owens <[email protected]>

Quoted 3 lines

No need for a separate size field. Note that MODULE_PARM is built at compile time so all persistent data must have a fixed compile time size.

I'll buy that - but it does mean that if there are 300 items then it will get LONG... but then, that can be handled. I was thinking of the "parameter" to possibly being a full data structure that could be updated in an atomic manner, with a minimum of overhead (no number conversions in the kernel).

Quoted 1 line

Pure binary immediately runs into kernel version skew problems.

The identification of data version should be left up to the userspace utility that retrieves the data.

For some things, yes. I was thinking of things like automatically changing the scheduling priorities for batch+interactive use. Also things like fair-share scheduler parameters, resident set size/swap resource control, (other large system capabilities, I admit).

I know it wasn't considered, but batch schedulers may have their parameters changed hourly. My site currently works with one that has parameters changed to reflect available resources for future scheduling cycles that use updated job priorities to determine how the system should respond.