[PATCH] Module parameters reimplementation 0/4

[PATCH] Module parameters reimplementation 0/4

[Rusty Russell]

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.

Re: [PATCH] Module parameters reimplementation 0/4

[Jeff Garzik]

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

Re: [PATCH] Module parameters reimplementation 0/4

[Rusty Russell]

In message <3DD323B4.6080404@pobox.com> 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.

Re: [PATCH] Module parameters reimplementation 0/4

[Andrey Panin]

[-- Attachment #1: Type: text/plain, Size: 373 bytes --]

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
pazke@orbita1.ru        | PGP key: wwwkeys.eu.pgp.net

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: [PATCH] Module parameters reimplementation 0/4

[Rusty Russell]

In message <20021114150325.GA313@pazke.ipt> 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.

Re: [PATCH] Module parameters reimplementation 0/4

[Matthew Wilcox]

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.

Re: [PATCH] Module parameters reimplementation 0/4

[Rusty Russell]

In message <20021114123940.U30392@parcelfarce.linux.theplanet.co.uk> 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.