Re: Compile-time versus run-time

[Keith Owens <kaos@ocs.com.au>]

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.