user/sven/linux.git/include/linux/moduleparam.h, branch v3.9

moduleparam: use __UNIQUE_ID()

2012-12-14T02:36:40Z

Signed-off-by: Rusty Russell

module_param: stop double-calling parameters.

2012-06-08T05:28:13Z

Commit 026cee0086fe1df4cf74691cf273062cc769617d "params: _initcall-like kernel parameters" set old-style module parameters to level 0. And we call those level 0 calls where we used to, early in start_kernel(). We also loop through the initcall levels and call the levelled module_params before the corresponding initcall. Unfortunately level 0 is early_init(), so we call the standard module_param calls twice. (Turns out most things don't care, but at least ubi.mtd does). Change the level to -1 for standard module_param calls. Reported-by: Benoît Thébaudeau Signed-off-by: Rusty Russell Cc: stable@kernel.org

params: add 3rd arg to option handler callback signature

2012-04-30T18:05:27Z

Add a 3rd arg, named "doing", to unknown-options callbacks invoked from parse_args(). The arg is passed as: "Booting kernel" from start_kernel(), initcall_level_names[i] from do_initcall_level(), mod->name from load_module(), via parse_args(), parse_one() parse_args() already has the "name" parameter, which is renamed to "doing" to better reflect current uses 1,2 above. parse_args() passes it to an altered parse_one(), which now passes it down into the unknown option handler callbacks. The mod->name will be needed to handle dyndbg for loadable modules, since params passed by modprobe are not qualified (they do not have a "$modname." prefix), and by the time the unknown-param callback is called, the module name is not otherwise available. Minor tweaks: Add param-name to parse_one's pr_debug(), current message doesnt identify the param being handled, add it. Add a pr_info to print current level and level_name of the initcall, and number of registered initcalls at that level. This adds 7 lines to dmesg output, like: initlevel:6=device, 172 registered initcalls Drop "parameters" from initcall_level_names[], its unhelpful in the pr_info() added above. This array is passed into parse_args() by do_initcall_level(). CC: Rusty Russell Signed-off-by: Jim Cromie Acked-by: Jason Baron Signed-off-by: Greg Kroah-Hartman

params: _initcall-like kernel parameters

2012-03-26T02:20:51Z

This patch adds a set of macros that can be used to declare kernel parameters to be parsed _before_ initcalls at a chosen level are executed. We rename the now-unused "flags" field of struct kernel_param as the level. It's signed, for when we use this for early params as well, in future. Linker macro collating init calls had to be modified in order to add additional symbols between levels that are later used by the init code to split the calls into blocks. Signed-off-by: Pawel Moll Signed-off-by: Rusty Russell

module_param: remove support for bool parameters which are really int.

2012-03-26T02:20:51Z

module_param(bool) used to counter-intuitively take an int. In fddd5201 (mid-2009) we allowed bool or int/unsigned int using a messy trick. This eliminates that code (though leaves the flags field in the struct, for impending use). Signed-off-by: Rusty Russell

module_param: check that bool parameters really are bool.

2012-01-12T23:02:28Z

module_param(bool) used to counter-intuitively take an int. In fddd5201 (mid-2009) we allowed bool or int/unsigned int using a messy trick. This tightens the check (you'll get a warning about incompatible return type) but still allows it. Next kernel version, we'll remove it. Signed-off-by: Rusty Russell

module_param: avoid bool abuse, add bint for special cases.

2012-01-12T23:02:17Z

For historical reasons, we allow module_param(bool) to take an int (or an unsigned int). That's going away. A few drivers really want an int: they set it to -1 and a parameter will set it to 0 or 1. This sucks: reading them from sysfs will give 'Y' for both -1 and 1, but if we change it to an int, then the users might be broken (if they did "param" instead of "param=1"). Use a new 'bint' parser for them. (ntfs has a different problem: it needs an int for debug_msgs because it's also exposed via sysctl.) Cc: Steve Glendinning Cc: Jean Delvare Cc: Guenter Roeck Cc: Hoang-Nam Nguyen Cc: Christoph Raisch Cc: Roland Dreier Cc: Sean Hefty Cc: Hal Rosenstock Cc: linux390@de.ibm.com Cc: Anton Altaparmakov Cc: Jaroslav Kysela Cc: Takashi Iwai Cc: lm-sensors@lm-sensors.org Cc: linux-rdma@vger.kernel.org Cc: linux-s390@vger.kernel.org Cc: linux-ntfs-dev@lists.sourceforge.net Cc: alsa-devel@alsa-project.org Acked-by: Takashi Iwai (For the sound part) Acked-by: Guenter Roeck (For the hwmon driver) Signed-off-by: Rusty Russell

module_param: check type correctness for module_param_array

2012-01-12T23:02:16Z

module_param_array(), unlike its non-array cousins, didn't check the type of the variable. Fixing this found two bugs. Cc: Luca Risolia Cc: Mauro Carvalho Chehab Cc: Eric Piel Cc: linux-media@vger.kernel.org Signed-off-by: Rusty Russell

module.h: relocate MODULE_PARM_DESC into moduleparam.h

2011-10-31T13:20:11Z

There are files which use module_param and MODULE_PARM_DESC back to back. They only include moduleparam.h which makes sense, but the implicit presence of module.h everywhere hid the fact that MODULE_PARM_DESC wasn't in moduleparam.h at all. Relocate the macro to moduleparam.h so that the moduleparam infrastructure can be used independently of module.h Signed-off-by: Paul Gortmaker

params: make dashes and underscores in parameter names truly equal

2011-10-26T02:40:39Z

The user may use "foo-bar" for a kernel parameter defined as "foo_bar". Make sure it works the other way around too. Apply the equality of dashes and underscores on early_params and __setup params as well. The example given in Documentation/kernel-parameters.txt indicates that this is the intended behaviour. With the patch the kernel accepts "log-buf-len=1M" as expected. https://bugzilla.redhat.com/show_bug.cgi?id=744545 Signed-off-by: Michal Schmidt Signed-off-by: Rusty Russell (neatened implementations)