All of lore.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: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-14 20:07 [RFC PATCH] Allow optional module parameters Andy Lutomirski
2013-03-15  5:03 ` Rusty Russell
2013-03-15 18:18   ` Andy Lutomirski
2013-03-18  2:24     ` 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-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  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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.