| Age | Commit message (Collapse) | Author |
|---|
|
param_array() in kernel/params.c can now become static.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
Now when kbuild passes KBUILD_MODNAME with "" do not __stringify it when
used. Remove __stringnify for all users.
This also fixes the output of:
$ ls -l /sys/module/
drwxr-xr-x 4 root root 0 2006-01-05 14:24 pcmcia
drwxr-xr-x 4 root root 0 2006-01-05 14:24 pcmcia_core
drwxr-xr-x 3 root root 0 2006-01-05 14:24 "processor"
drwxr-xr-x 3 root root 0 2006-01-05 14:24 "psmouse"
The quoting of the module names will be gone again.
Thanks to GregKH + Kay Sievers for reproting this.
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
|
|
the part that got merged got broken on the way. Here are the fixes:
Move __MODULE_INFO to modparam.h: This macro is used in modparam.h;
there are users who include this header but not module.h. The latter
includes modparam.h already.
__MODULE_INFO(parmtype, name##type, #name ":" #type) does not evaluate
to __MODULE_INFO(parmtype, footype, "foo:int") as was the idea, but to
__MODULE_INFO(parmtype, fooint, "foo:int") when type is bound to int.
In more complicated cases, we get syntax erros. Re-introduce the
__MODULE_PARM_TYPE macro; this is cleaner than renaming the type parameter.
Add the parmtype definition which was dropped during the merge to to the
obsolete but still heavily used MODULE_PARM macro.
Signed-off-by: Andreas Gruenbacher <agruen@suse.de>
Signed-off-by: Sam Ravnborf <sam@ravnbrg.org>
|
|
Module parameters no longer have a type in general, as we use a callback
system (module_param_call()). However, it's useful to include type
information in the commonly-used wrappers: module_param,
module_param_string and module_param_array.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
Currently, only module parameters in loaded modules are exported in
/sys/modules/, while those of "modules" built into the kernel can be set by
the kernel command line, but not read or set via sysfs.
- move module parameters from /sys/modules/$(module_name)/$(parameter_name) to
/sys/modules/$(module_name)/parameters/$(parameter_name)
- remove dummy kernel_param for exporting refcnt, add "struct module *"-based
attribute instead
- also export module paramters for "modules" which are built into the kernel,
so parameters are always accessible at
/sys/modules/$(KBUILD_MODNAME)/$(parameter_name)
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> (modified)
Signed-off-by: Dominik Brodowski <linux@brodo.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
module_param_array() takes a variable to put the number of elements in.
Looking through the uses, many people don't care, so they declare a dummy
or share one variable between several parameters. The latter is
problematic because sysfs uses that number to decide how many to display.
The solution is to change the variable arg to a pointer, and if the pointer
is NULL, use the "max" value. This change is fairly small, but fixing up
the callers is a lot of (trivial) churn.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
into ppc970.osdl.org:/home/torvalds/v2.6/linux
Manual merge of kernel/params.c clashes.
|
|
Reading the contents of a module_param_string through sysfs currently
oopses because the param_get_charp() function cannot operate on a
kparam_string struct. This introduces the required param_get_string.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
|
|
From: Rusty Russell <rusty@rustcorp.com.au>
From: Pavel Machek <pavel@ucw.cz>
If we are providing "helpful" comment, it should better be correct.
|
|
This patch adds basic kobject support to struct module, and it creates a
/sys/module directory which contains all of the individual modules. Each
module currently exports the refcount (if they are unloadable) and any
module paramaters that are marked exportable in sysfs.
Was written by me and Rusty over and over many times during the past 6 months.
|
|
name different form corresponding array variable. Allows using short
(but descriptive) option names without hurting code readability.
Modeled after module_param_named.
|
|
From: David Mosberger <davidm@napali.hpl.hp.com>
With gcc-3.4 we need "attribute((used))" declarations to get "make
modules_install" to work.
Otherwise these sections get dropped from the final image (I assume).
|
|
From: Rusty Russell <rusty@rustcorp.com.au>
Found this while converting netfilter modules to use the new
parameters. Also fixes an out-by-one error in maximum elements you
can put in array.
The current "intarray" module params were never tested, and um, suck.
Only one person uses them, and it looks painful.
Since noone uses them, replace them with tested versions.
|
|
Thanks to Jan Hubicka who suggested this fix.
The problem seems to be that gcc generates a 32byte alignment for static
objects > 32bytes. This causes gas to set a high alignment on the
section, which causes the uneven (not multiple of sizeof(struct
kernel_param)) section size. The pointer division with a base not being
a multiple of sizeof(*ptr) then causes the invalid result.
This just forces a small alignment, which makes the section end come out
with the correct alignment.
The only mystery left is why ld chose a 16 byte padding instead of
32byte.
|
|
Add a const declaration to the __module_param_call so __param section
gets more correct attributes.
|
|
This patch is a rewrite of the insmod and boot parameter handling,
to unify them.
The new format is fairly simple: built on top of __module_param_call there
are several helpers, eg "module_param(foo, int, 000)". The final argument
is the permissions bits, for exposing parameters in sysfs (if
non-zero) at a later stage.
|
