Messages in this thread |  | | From | (David Hinds) | Subject | Proposal for cleaning up kernel driver parameters | Date | 12 Dec 1996 23:05:49 GMT |
| |
I've been thinking about how to best implement a "unified" way of setting driver parameters for kernel-resident and modularized drivers. This is what I think would be a nice, clean way of handling driver parameters...
-- Treat the boot command line as a set of environment strings for the kernel. Drivers should be able to look things up by name, using an equivalent of getenv(). Take all the code for calling *_setup functions out of init/main.c: each driver should handle retrieving its own parameters.
-- Implement the equivalent of the SYSV getsubopt() library function for the kernel. This function treats an argument as a series of comma-separated options, which may be keywords or keyword=value pairs.
-- For backwards compatibility, we'll also have a kernel function that parses an argument into an array of ints, as the old *_setup() functions expect.
To implement all this, we need to:
-- Add the new parsing routines to the kernel.
-- One by one, edit init/main.c to remove a *_setup() call, and modify the corresponding driver to use the new parsing routines.
-- Later, modify the drivers to use keyword=value options, rather than the old int,int,int stuff.
For modules, we could pass options in like:
insmod i82365.o opts="irq_mask=0xefff,poll_status"
and the module can then parse the option string using the same code it would use if linked into the kernel.
Advantages:
-- Maintains nearly complete backwards compatibility. The only driver I know of that does its own fancy/incompatible boot line parsing is the IDE driver.
-- More flexible, sane way of setting lots of parameters than the old "1[,2[,3[,4[,5[,6[,7]]]]]]" boot parameter scheme.
-- Potentially safer than insmod's "modify any static symbol at will" scheme.
-- Eliminates init/main.c dependencies on many config parameters. Which is part of my long-term goal of making driver selection just a link-time step :)
Disadvantages:
-- More code required for stuff only done at initialization time. But I think the overhead should be pretty small: most drivers will just add a few keywords. I'd guess fewer than 100 bytes per driver for most drivers. And some drivers (like IDE) already have a lot of private code for doing essentially the same thing.
What do people think? As another project, I've been thinking about how to provide a nicer interface for exposing "tuneable" kernel parameters so that they can be read/written on the fly. There are a few in /proc already, but I'd like to see lots more.
-- Dave Hinds dhinds@hyper.stanford.edu
|  |