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

Rusty Russell (rusty@rustcorp.com.au)
Wed, 18 Dec 2002 13:24:57 +1100


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.
-
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/