-- 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