From: Rusty Russell <rusty@rustcorp.com.au>
To: Andy Lutomirski <luto@amacapital.net>
Cc: linux-kernel@vger.kernel.org,
Ben Hutchings <bhutchings@solarflare.com>,
linux-kbuild@vger.kernel.org, Jon Masters <jcm@redhat.com>,
Lucas De Marchi <lucas.demarchi@profusion.mobi>
Subject: Re: [RFC PATCH] Allow optional module parameters
Date: Tue, 19 Mar 2013 13:02:50 +1030 [thread overview]
Message-ID: <87hak8qfu5.fsf@rustcorp.com.au> (raw)
In-Reply-To: <CALCETrUK54KViGex=V2pG8kAttsxOiDkeJUL48pk1NAhH-SdAA@mail.gmail.com>
Andy Lutomirski <luto@amacapital.net> writes:
> On Sun, Mar 17, 2013 at 7:24 PM, Rusty Russell <rusty@rustcorp.com.au> wrote:
>> Andy Lutomirski <luto@amacapital.net> writes:
>>> On Thu, Mar 14, 2013 at 10:03 PM, Rusty Russell <rusty@rustcorp.com.au> wrote:
>>>> Err, yes. Don't remove module parameters, they're part of the API. Do
>>>> you have a particular example?
>>>
>>> So things like i915.i915_enable_ppgtt, which is there to enable
>>> something experimental, needs to stay forever once the relevant
>>> feature becomes non-experimental and non-optional? This seems silly.
...
>>> Having the module parameter go away while still allowing the module to
>>> load seems like a good solution (possibly with a warning in the logs
>>> so the user can eventually delete the parameter).
>>
>> Why not do that for *every* missing parameter then? Why have this weird
>> notation where the user must know that the parameter might one day go
>> away?
>
> Fair enough. What about the other approach, then? Always warn if an
> option doesn't match (built-in or otherwise) but load the module
> anyways.
What does everyone think of this? Jon, Lucas, does this match your
experience?
Thanks,
Rusty.
Subject: modules: don't fail to load on unknown parameters.
Although parameters are supposed to be part of the kernel API, experimental
parameters are often removed. In addition, downgrading a kernel might cause
previously-working modules to fail to load.
On balance, it's probably better to warn, and load the module anyway.
Reported-by: Andy Lutomirski <luto@amacapital.net>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
diff --git a/kernel/module.c b/kernel/module.c
index 3c2c72d..46db10a 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -3206,6 +3206,17 @@ out:
return err;
}
+static int unknown_module_param_cb(char *param, char *val, const char *modname)
+{
+ /* Check for magic 'dyndbg' arg */
+ int ret = ddebug_dyndbg_module_param_cb(param, val, modname);
+ if (ret != 0) {
+ printk(KERN_WARNING "%s: unknown parameter '%s' ignored\n",
+ modname, param);
+ }
+ return 0;
+}
+
/* Allocate and load the module: note that size of section 0 is always
zero, and we rely on this for optional sections. */
static int load_module(struct load_info *info, const char __user *uargs,
@@ -3292,7 +3303,7 @@ static int load_module(struct load_info *info, const char __user *uargs,
/* Module is ready to execute: parsing args may do that. */
err = parse_args(mod->name, mod->args, mod->kp, mod->num_kp,
- -32768, 32767, &ddebug_dyndbg_module_param_cb);
+ -32768, 32767, unknown_module_param_cb);
if (err < 0)
goto bug_cleanup;
next prev parent reply other threads:[~2013-03-19 4:55 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <b6b1676fd5bcd6b0ef47b0e0a1c26b1c05684135.1363291511.git.luto@amacapital.net>
[not found] ` <87ehfhtftn.fsf@rustcorp.com.au>
[not found] ` <CALCETrU+rehQzy4vVg589CGi561X_s73Xgsfp43pYZOoKvNDXQ@mail.gmail.com>
2013-03-18 2:24 ` [RFC PATCH] Allow optional module parameters Rusty Russell
2013-03-18 17:42 ` Andy Lutomirski
2013-03-19 2:32 ` Rusty Russell [this message]
2013-03-19 19:40 ` Ben Hutchings
2013-03-20 2:31 ` Rusty Russell
2013-03-20 0:26 ` Lucas De Marchi
2013-03-20 0:32 ` Andy Lutomirski
2013-03-20 0:36 ` Andy Lutomirski
2013-03-20 3:45 ` Rusty Russell
2013-07-01 6:50 ` Rusty Russell
2013-07-01 16:33 ` Jonathan Masters
2013-07-03 0:28 ` Rusty Russell
2013-07-03 21:03 ` Michal Marek
2013-07-03 21:17 ` Andy Lutomirski
2013-07-03 21:23 ` Michal Marek
2013-07-03 21:30 ` Yann E. MORIN
2013-07-03 21:31 ` Lucas De Marchi
2013-07-03 21:36 ` Andy Lutomirski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87hak8qfu5.fsf@rustcorp.com.au \
--to=rusty@rustcorp.com.au \
--cc=bhutchings@solarflare.com \
--cc=jcm@redhat.com \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lucas.demarchi@profusion.mobi \
--cc=luto@amacapital.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox