Re: [PATCH 2/8] param: use ops in struct kernel_param, rather than get and set fns directly

At Fri, 30 Oct 2009 21:43:39 +1030,
Rusty Russell wrote:

On Fri, 30 Oct 2009 08:48:12 pm Takashi Iwai wrote:

quoted

At Fri, 23 Oct 2009 00:51:28 +1030,
Rusty Russell wrote:

quoted

This is more kernel-ish, saves some space, and also allows us to
expand the ops without breaking all the callers who are happy for the
new members to be NULL.

The few places which defined their own param types are changed to the
new scheme.

Since we're touching them anyway, we change get and set to take a
const struct kernel_param (which they were, and will be again).

To reduce churn, module_param_call creates the ops struct so the callers
don't have to change (and casts the functions to reduce warnings).
The modern version which takes an ops struct is called module_param_cb.

This is nice, as it also reduces the size of struct kernel_param, so
each parameter uses less footprint (who cares, though?) :)

But, just wondering whether we still need to export get/set
functions.  They can be called from ops now, so if any, it can be
defined even as an inlinefunction or a macro.

My thought too, so I tried that, but many are still used like so:

	module_param_call(foo, set_foo, param_get_uint, NULL, 0644);

They can all be replaced in time with something like:
	static int param_get_foo(char *buffer, const struct kernel_param *kp)
	{
		return param_ops_uint.get(buffer, kp);
	}

But it'll take a transition period.

Fair enough.  And, maybe these get/set should be defined as an ops
explicitly so that it can be used for multiple parameters.  But we
can do cleanups later, of course :)

Oh, in case you need,
	Reviewed-by: Takashi Iwai [off-list ref]
for all new patches.


Thanks!

Takashi