Re: [PATCH] : More module parameter compatibility for 2.5.52

[Rusty Russell <rusty@rustcorp.com.au>]

In message <20021217173346.GA22924@bougret.hpl.hp.com> you write:
> On Tue, Dec 17, 2002 at 03:20:10PM +1100, Rusty Russell wrote:
> > I prefer the fix below.  Does it work for you?
> > 
> > Rusty.
> 
> 	With all due respect, your fix is quite ugly.

Yes.

> 	And think about it this way : your new param architecture is
> supposed to be flexible and supposed to allow modules to get
> parameters in any shape or form. But, on the other hand, it's
> impossible to implement something as simple as 'c' without ugly hacks.

'c' is trivial.  1-20c50, which is a the two dimensional array of
variable bounds, which is outside the scope of current param_array
implementation (which was designed to handle 1d arrays).

> 	Maybe we can deduct from this that the new param API is not
> flexible enough and that the simple addition of an opaque type (priv)
> can have some value.

They *do* have a mechanism to pass extra parameters (kp->arg), it's
just that the standard "param_array" code already uses it to hand the
address of the variable.  Your patch added a second one.

The new param code was not meant to do *everything*, it was meant to
add type safety and unification of boot and module parameters, and
allow extensibility.

I think you're confusing "param_array() doesn't handle 2d arrays" with
"infrastructure not powerful enough".  Since __module_param_call() is
functionally equivalent to __setup(), the second one seems unlikely.

Writing such an extension is a job for the next mail...

Does that clarify?
Rusty.
--
  Anyone who quotes me in their sig is an idiot. -- Rusty Russell.