LWN: Comments on "Driver porting: more module changes"

Driver porting: more module changes

linuxosa — 2004-07-22T07:53:40+00:00

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

Driver porting to 2.5.59: 'MOD_IN_USE' undeclared

hsieng — 2003-02-27T08:12:43+00:00

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

rrw — 2003-02-21T10:17:43+00:00

I think that there is one problem with this scheme of parameters. In case of numbers you cannot distinguish if the user didn't set the parameter or if he has set it to zero. Perheaps example will explain it better:

module_param(howmany, int, 0);

if you load this module with howmany=0, howmany will be zero. But if you omit howmany on modload commandline, howmany will be also zero.

One should pass the numeric arguments to the code as (int *), not the (int). Then NULL will be ``not set''.

Driver porting: more module changes

mmarq — 2003-02-21T06:35:25+00:00

Well, I wonder why bother, ...perahps going for one of the kernel maintainers listed emails,...but then, if anyone can answer to this question i'l be very much appreciataded...it's very important to me!!!

Does this >"new "version magic" scheme also records other information, including the compiler version, SMP status, and preempt status; it is thus able to catch more incompatible situations than the old scheme did"<, storm, is to be lefted in production 2.6 kernels, or is it going to be somehow abstracted??

Better put!, does a "stupid trying to be a hacker" programmer like me, if by any change achieves the feat of getting a working kernel hardware driver module for the most trivial piece of hardware in the world, say, compiled with kernel 2.6.6 and gcc 3.4, "be in a versioning storm" and have to fix the module for it to recompile with preempt enable, and fix the module againg for it to recompile with SMP enabled, and for Kernel 2.6.7 the same, and for gcc3.4.1 the same,..., meaning that 20 kernel versions and 3 compiler versions ahead i would have to make 180 fixes!?????

whaw!!...without meaning any disrespect, it sure is a job for a full time payed hacker!

Well!!...If the answer is yes than is very sad "for me and for thousands like me,...because i have a very small shop that transforms old gear and also produce new linux servers and firewall appliences, and dont have the many to hire an army of programmers.

Its double sad, because after 10 years of dreams and foughts, the kernel is sleeping to the hands of IBM, HP and the like, that not only have the resources for thousands of programmers, but also control the machines on witch full working kernels can be deployed.

Any way, i respectfuly be waiting for a answer.... thank you.

Driver porting: more module changes

rusty — 2003-02-14T08:41:21+00:00

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.