Re: Suggestion for handling of boot-time driver options

Grant R. Guenther (
Sat, 13 Dec 1997 16:29:09 -0500 (EST)

> I just saw that init/main.c is full of constructs of the form
> { "ez=", ez_setup },
> #endif

> This could be achieved more elegantly (and without cluttering init/main.c
> with entries for every setup function imaginable) with some ELF linking
> magic.

Actually, this is something I've been thinking about for a long time,
but never got around to looking into seriously.

> BOOTSETUP( "floppy=", floppy_setup );
> into drivers/block/floppy.c (where floppy_setup is implemented anyway)

I think you will also need some kind of sorting flag - as some modules
must be initialised before others (owing to conflicting probes, for
instance). Most modules won't care, but some do, so a facility is needed.

> Any suggestions, objections, flames?

I'd also like to see a small syntactic enhancement. It should also
be possible to set parameters with a notation like:


Which would be _exactly_ equivalent to


With this convention in place, it will be possible for almost all
modules to use compatible parameterisation schemes in both
their built-in and LKM manifestations.

As an example, the new replacement for the ez driver takes an insmod
command like:

insmod pd drive0=0x378,1,36 drive1=0x278,0 verbose=1

Once built in to the kernel, I'd like to be able to tune it with
a command line like:

pd.drive0=0x378,1,63 pd.drive1=0x278,0 pd.verbose=1

with exactly the same effect.

This scheme could be further advanced if it was combined with
Richard Henderson's "MODULE_PARM" facilty, so that the module's
"setup" function could be automatically constructed from the
information in the MODULE_PARM declarations. I figure that's
just some more ELF trickery ...

Grant R. Guenther