Re: Suggestion for handling of boot-time driver options

Roderich Schupp (
Sun, 14 Dec 1997 18:25:33 +0100 said:
> You need to preserve the existing order of entries in main.c *AND*
> give users the ability to tweak that order for their own unique
> requirements. The existing order is important because the probe code
> has to look at some cards before others.
My suggestion was about the parsing of the boot line parameters
and not about initializing drivers. As far as I can tell there is
no ordering constraint on the lookup table
"option=" -> option_setup_function
(some kernel options are processed beforehand, though,
but still the line is processed "from left to right").
However, driver initialization would be the next thing on the agenda,
getting rid of things like
#ifdef CONFIG_CDROM /* this must precede all CD-ROM drivers */
(in blk_dev_init in drivers/block/ll_rw_blk.c, similar misc_init
in drivers/char/misc.c, probably others).

> Possibly add an "order" flag to the BOOTSETUP macro and give every
> setup code a unique order number. Start in increments of 1,000 to
> leave room for future inserts. main.c sorts the entries before
> running the setup code in "order". Preserves the existing sequence
> and users can change order numbers to suit their own requirements.
Except that this macro would be called INIT and called like
INIT( loop_init, 1001 );
or maybe add a tag string
INIT( "loop", loop_init, 1001 );
and some convention that a boot line option of "order_foo=1002"
allows you to change the order value for tag "foo" to 1002?
OTOH, this should perhaps better be left to a configuration manager
of sorts.
Cheers, Roderich

  Do not meddle in the affairs of wizards, for they are subtle and quick
  to anger.  Do not meddle in the affairs of dragons for you are crunchy
  and taste good with ketchup.  Do not meddle in the affairs of cats, for
  they are subtle and will piss on your computer.
Roderich Schupp
ExperTeam GmbH 
Munich, Germany               Linux: 2.1.72