Re: Compile-time versus run-time

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.

Re: Compile-time versus run-time

[Keith Owens]

On Tue, 27 Mar 2001 08:26:53 -0500, 
Jeff Garzik <jgarzik@mandrakesoft.com> wrote:
>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.

Implementation detail.  module.{opt1=value opt2=value} will save some
space but the module name is still required, multiple objects use
variable names like io and irq.

>* 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.

I'm not convinced that we need a distinction.  If you can specify a
parameter as a module you can specify it at boot time.  If there are
any cases where the parameter makes no sense at boot time, the code can
ignore any value when it is compiled for built in mode.

In any case it must be a gradual conversion.  A lot of code has #ifdef
MODULE around the parameter identifiers, #ifdef must be removed to use
both methods, otherwise you get undefined variables.  So only modules
that are compiled with a new flag will get the feature.  Later in the
2.5 cycle the common parameter handling will become the default.