I was going to feed this more slowly, to get feedback at every stage,
but I'm being mailbombed by angry developers 8(
Explanation: (Not that anyone read my previous ones, it seems)
1) MODULE_PARM() is not typesafe: it doesn't even check that the
variable exists. There are dozens of completely bogus uses in
drivers.
2) Everyone who wants to implement module parameters *and* boot
parameters had to implement MODULE_PARM() and __setup() and roll
their own parsing.
3) MODULE_PARM() is not extensible.
This patch series introduces "PARAM(var, type, perm)". This does
several things:
1) Checks the type of "var" matches "type".
2) If built-in, adds a boot parameter called <modulename>.var.
3) If modular, adds a module parameter called var.
4) The third arg is for exposure through sysfs once it stabilizes, 000
means don't expose.
PARAM() is implemented in terms of PARAM_CALL(), similar to __setup()
except it (depending on the perm field) might be readable too.
Types "short", "ushort", "int", "ulong", "bool", "invbool" etc are
implemented pre-canned. You can define your own, see linux/params.h
for how.
Finally, if you do not use your own types, PARAM() can be #defined
into a MODULE_PARM statement for 2.4 kernels (ie. backwards
compatible). Patch 4/4 also translates old-style MODULE_PARM() into
PARAMs at load time, for existing modules.
Why now?
--------
This kind of change shows why you need an in-kernel linker: this kind
of change would break userspace with the current modutils.
Sorry for any inconvenience,
Rusty.
-- Anyone who quotes me in their sig is an idiot. -- Rusty Russell. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Nov 15 2002 - 22:00:31 EST