Re: Compile-time versus run-time

[Jeff Garzik]

Keith Owens wrote:
> Andrew Morton wrote:
> > CONFIG_8139TOO_TUNE_TWISTER
> > (And wouldn't it be nice to be able to get the same functionality
> > which module options give us when using a statically linked driver?)
> 
> On my todo list for 2.5.  MODULE_PARM will be promoted to
> module_name.parm when the object is built in.  insmod foo debug=1 or
> boot with foo.debug=1.  It needs a mapping of source to module which is
> not easy to get for multi object modules in 2.4, my 2.5 makefile
> rewrite will make it easy.

(redirect to lkml)

Making MODULE_PARM work when compiled in will be nice, but I see two
flaws right off:

* passing multiple module parms is wasteful, because the module prefix
must be repeated for each argument.  That strains cmdline limits (80
chars in boot environments)  IMHO we can do better than that.

* There are cases where you do not want MODULE_PARM options appearing as
__setup, just like there are cases where options passed to __setup do
not belong as a MODULE_PARM.  You should not unconditionally make
MODULE_PARM available on the kernel command line, even though that is
the simple solution.

-- 
Jeff Garzik       | May you have warm words on a cold evening,
Building 1024     | a full moon on a dark night,
MandrakeSoft      | and a smooth road all the way to your door.