Re: Documentation

Grant R. Guenther (
Thu, 30 May 1996 10:02:10 -0400 (EDT)

Lauri Tischler wrote:
> Is there anyplace where _ALL_ configuration parameters are in ONE
> place. Like Matti Aarnio's README about net modules.
> A document where are all module parameters would be very handy.
> Also paper where are all LILO/LOADLIN parameters in case module is
> permanent in kernel.
> This could (and should) be one all-embraicing document.

Paul Gortmaker does maintain the BOOTPROMPT HOWTO - which covers
the LILO/LOADLIN parameters.

But, I've responded to this for another reason. Here's some mail I sent
to Bjorn in March:

As I was doing the final steps to get my driver integrated into the kernel
tree, I got to thinking about the silliness of having two distinct ways
of tailoring modules depending on whether they are linked into the kernel
or loaded with insmod.

If this is an issue that's been thrashed about before and I missed it,
I apologise for bringing it up again, but I really don't see any good
reason for the current situation.

Consider my driver, ppa. If it is built in to the kernel, main.c will
call ppa_setup after parsing something of the form


And ppa_setup will do the assignments:

ppa_base=0x378; ppa_speed_high=0; ppa_speed_low=3;

But if the driver is built as a module, it must be inserted with the

insmod ppa.o ppa_base=0x378 ppa_speed_high=0 ppa_speed_low=3

to achieve the same effect.

The same applies for many other device drivers.

Apart from the aesthetic problem of different notations, I believe the
current approach of allowing insmod to alter any addressable location
to be much riskier, especially with the new boot loaders that will allow
distribution builders to make boot disks that depend on loadable modules.

It seems to me that insmod should arrange for each module's initialisation
code to be passed pointers appropriate for passing on to the module's
*_setup routine. Finding the most elegant way of coding this without
breaking any current functionality would be an interesting exercise.

I'd probably use the current mechanism to pass the command line arguments
unparsed as a string and then provide a macro that did the parsing and
passed the resulting pointers on to *_setup. In time, this would become
part of the boiler-plate for creating a new module.

Well, before I blabber on any further, what do you think ? If you guys think
it's a really dumb idea, I'll just drop it :-)

It seems that Bj0rn must have thought it a dumb idea, as I never had
any response. But Lauri's question has re-opened the issue for me, so
I'm picking it up again. Does anyone agree with me ?

Grant R. Guenther