Kernel Parameters

"Kernel parameters" are just ways of controlling how the kernel operates. Typically, they can be specified at boot time (on the command line), at module load time, or at run time through /proc, a system call, or some other interface. Each way of handling parameters requires a different bit of code, so many kernel subsystems do not implement all the different ways of setting parameters. This session looked at two different approaches for unifying the handling of kernel parameters.

Rusty Russell presented his scheme for handling kernel parameters. It involves replacing the MODULE_PARM macro with a new PARAM macro which would set up a parameter for the boot command line, module insertion, and /proc. Unlike MODULE_PARM, the new scheme is type safe (i.e. the compiler catches type errors). It is also based on a callback mechanism which makes it easy for a module to define new parameter types if need be.

The other approach was presented by Patrick Mochel. As part of his ongoing driver model work, he implemented "driverfs," the driver filesystem. driverfs is a virtual filesystem initially developed as a debugging tool; it is a convenient way of looking at the structure of the device tree. The facilities provided by driverfs are similar to those provided by Rusty's scheme; driverfs, too, is type-safe and easy to set up. It is also, for now, limited to device drivers only; the question is whether it should be expanded to handle kernel parameters in general.

While no conclusions were drawn in the session, driverfs looks (to your author) like it is here to stay, since it so nicely incorporates the system's structure in the filesystem it creates. It just needs to be expanded to cover all of the other types of parameters in the system (i.e. VM, networking, etc.) that are not directly associated with devices. A merger with some variant Rusty's scheme would help in that regard, and seems likely at some point.

Linus pointed out that he would like to see a single, integrated filesystem that includes all such information. Thus, for example, the "fsfs" that provides filesystem information can include links to the underlying devices holding those filesystems. Module information can link to the associated driver and devices. Such a filesystem, he said, makes the linkages in the system visible and explicit.

Eventually, /proc could be phased out in favor of a driverfs-like system, with a "one file, one value" rule. This change really has to begin in 2.5, since /proc has to be supported for at least one more stable kernel cycle. Expect to see more activity in this area in the near future.