lkml.org 
[lkml]   [1996]   [Dec]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectProposal for cleaning up kernel driver parameters
Date

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

\
 
 \ /
  Last update: 2005-03-22 13:38    [W:0.148 / U:0.040 seconds]
©2003-2011 Jasper Spaans. Advertise on this site