public inbox for linux-kbuild@vger.kernel.org
 help / color / mirror / Atom feed
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;
 

  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