Driver porting: more module changes

Posted Feb 14, 2003 8:41 UTC (Fri) by rusty (guest, #26)
Parent article: Driver porting: more module changes

Regarding module_param(): MODULE_PARM() will certainly stay throughout the 2.6 series, so no need to change existing code just yet.

However, the real power of module_param() is that you can easily build your own types: i.e. it is extensible. One way to do this is to use the underlying module_param_call() macro, but a more convenient way goes like this:

 #define param_check_mytype(name, p) /* optional typechecking */
 int param_set_mytype(const char *val, struct kernel_param *kp) ...
 int param_get_mytype(char *buffer, struct kernel_param *kp) ...

Then you can use it as follows:

 module_param(myparam, mytype, 000);

This is extremely useful for implementing things like ranges, or any holes in the provided macros.

The other issue to note is that (as an unrelated bonus) the module_param parameters are also available as boot parameters, prefixed with the module name and a "." (- and _ can be used interchangably here). Previously __setup() was needed for boot parameters, and MODULE_PARM for module parameters.

Hope that helps!
Rusty.

Driver porting to 2.5.59: 'MOD_IN_USE' undeclared

Posted Feb 27, 2003 8:12 UTC (Thu) by hsieng (guest, #9844) [Link]

Hello,

While compiling a device driver in 2.5.59, I get the following error:

dmodule.c: 'MOD_IN_USE' undeclared

Please help on how to solve this problem.

Thank you.

Se-Hsieng

Driver porting: more module changes

Posted Jul 22, 2004 7:53 UTC (Thu) by linuxosa (guest, #23278) [Link]

why the standand kernel source linux/moduleparam.h doesn't have:

extern int param_set_byte(const char *val, struct kernel_param *kp); extern int param_get_byte(char *buffer, struct kernel_param *kp);

but the comments says:

/* Helper functions: type is byte, short, ushort, int, uint, long, ulong, charp, bool or invbool, or XXX if you define param_get_XXX, param_set_XXX and param_check_XXX. */