Module parameters reimplementation 0/4

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.

Let's be more friendly to the namespace and call it something less ambiguous, like MODULE_PARAM, even if that might not be strictly true in 1% of the cases. IMO there are certainly valid local uses of 'PARAM' in kernel code.

You can see from the totally gratuitous patch to include/asm-i386/setup.h which should have been a clue...

If this was C++ we could just stick PARAM in the "rusty" namespace and be done with it, but such as things are...... ;-)

Jeff

In message <[email protected]> you write:

I disagree. It's a param, subsuming both __setup and MODULE_PARAM. The fact that it is implemented for modules is not something for the driver author to be concerned about (finally).

IMHO, fundamental elements deserve fundamental names.

Cheers,
Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.

Why not u8, u16, u32 etc ?

Andrey Panin            | Embedded systems software developer
[email protected]        | PGP key: wwwkeys.eu.pgp.net

In message <[email protected]> you write:

I could have, but in practice that doesn't seem to be how people use them. But that may be a legacy of MODULE_PARM(). If I guessed wrong, more can be added trivially.

Cheers,
Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.