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/