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.
Rusty Russell wrote:
> 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.
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:
> Rusty Russell wrote:
>
> > 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.
>
> 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.
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.
> You can see from the totally gratuitous patch to
> include/asm-i386/setup.h which should have been a clue...
>From which I am confident that noone else in i386, at least, uses it 8)
Cheers,
Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
Rusty wrote:
> Jgarzik wrote:
> > 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.
>
> 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).
You're both wrong ;-) `module' != `loadable module'. module_init()
means `this is where you initialise this module', whether it's built-in
or synamically loaded. MODULE_PARAM() should mean `this is a parameter
for this module', whether it's built-in or dynamically loaded.
--
Revolutions do not require corporate support.
On Чтв, Ноя 14, 2002 at 03:23:00 +1100, Rusty Russell wrote:
> Types "short", "ushort", "int", "ulong", "bool", "invbool" etc are
> implemented pre-canned. You can define your own, see linux/params.h
> for how.
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:
> Rusty wrote:
> > Jgarzik wrote:
> > > 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.
> >
> > 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).
>
> You're both wrong ;-) `module' != `loadable module'.
Now we're descending into sophistry. But PARAM() is useful in (say)
init/main.c, as well, and it's a stretch to call it a module...
Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
In message <[email protected]> you write:
>
> --BwCQnh7xodEAoBMC
> Content-Type: text/plain; charset=utf-8
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable
>
> On =D0=A7=D1=82=D0=B2, =D0=9D=D0=BE=D1=8F 14, 2002 at 03:23:00 +1100, Rusty=
> Russell wrote:
> > Types "short", "ushort", "int", "ulong", "bool", "invbool" etc are
> > implemented pre-canned. You can define your own, see linux/params.h
> > for how.
> Why not u8, u16, u32 etc ?
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.