From: Brian Julin <bri@forcade.calyx.net>
  To  : ggi-develop@eskimo.com
  Date: Mon, 22 Feb 1999 19:42:20 -0500 (EST)

Load-time parameters

Can we get insmod/runtime parameters worked out as one of our first
orders of business?  As far as I can tell the "KGI managed" system
for these has been dysfunctional for quite some time.  

There are two major things that are complicating this issue.

The first is that we have interchangable sub-modules that need to share
some of the module parameters, but at the same time there are some
parameters which are pretty much exclusive to certain specific
chipsets -- so we oscillate between trying to centralize/standardize
things and letting the sub-modules all go their own separate
directions.

The second is that one module may be handling more than one 
hardware instance and must have a set of parameters for each one.

There are three basic options to choose from:

1) Link in symbols as per insmod.  Convenient, parsing is done
in userspace, but causes the abovementioned headache for sub-modules.
Also clumsy in that multi-card setups have to collate their
parameters e.g. law_base=0xf0000000,0xe000000 law_size=0x10000000,0x10000000
                         ^^ card 1  ^^ card 2          ^^ card 1  ^^ card2
...which is especially bad when you want to pass a single card an array 
of values.

2) Send in a string per insmod and parse it ourselves.  Better 
for standardization and for multi-card setup, but requires us to 
provide parsing facilities in-kernel and devlop a syntax.

3) Use a procfs/sysctl type interface -- insert the module, create
an instance, tweak the parameters, and then send a command to "activate" 
a peice of hardware.  But will an adequate, interactive, sysctl style 
interface be available on all target OS's??  Also, this still does
parse things in-kernel though in a less complex way than #2

A fourth possibility not very discussed is a userland utility that
is basically an extension to insmod to pre-chew the module parameters
before inserting the modules.

#3 alone has the ability to do runtime configuration when hardware
is changed e.g. changing monitors.

My personal wish is to avoid linking symbols runtime, rather allocate
per-card options structures on the fly, and to allow insertion of 
sub-modules individually instead of linking them all together first 
and then inserting them, but I'm more wanting an agreed-to standard 
than to get my way :).

--
P.C.M.C.I.A. stands for "Plastic Connectors May Crack If Adjusted"
                                                             -- me
--
Brian S. Julin