Ldd3 Reading Notes Chapter 1 Creation and operation module

Module Parameters

The parameters that the driver needs to know vary with systems. from the device number used (as we will see in the next chapter) to the driver's operations. for example, the SCSI Adapter Driver often has options to control the use of the tag command queue, and the IDE driver allows users to control DMA operations. if your driver controls the old hardware, you need to be clearly indicated where to find the hardware I/O port or I/O memory address. the kernel supports these requirements by specifying variable parameter values when loading the driver module.

The value of these parameters can be specified when insmod or modprobe is loaded. The latter can also be specified from its configuration file (/etc/modprobe. conf) read the parameter value. these commands accept values of several types in the command line. as a way to demonstrate this capability, imagine a particularly important improvement to the "Hello World" module (called hellop) at the beginning of this chapter. we add two parameters: an integer value called how.pdf and a string called whom. when loading our special function modules, welcome.
Whom is more than once, but howmany times. Such a module can be loaded using such command lines:

insmod hellop howmany=10 whom="Mom" 

Once loaded in that way, hellop will say "Hello, mom" 10 times.

However, before insmod can modify module parameters, the module must make them available. the parameter is declared using the moudle_param macro definition, which is defined in moduleparam. h. module_param uses three parameters: variable name, its type, and a permission mask for auxiliary sysfs entry. this macro definition should be placed outside of any function, typically in front of the source file. therefore, hellop declares its parameters and makes it available to insmod as follows:

Static char * Whom = "world ";

Static int howtasks = 1;

Module_param (howmany, Int, s_irugo );

Module_param (whom, CHARP, s_irugo );

The module parameters support many types:

Bool

Invbool

A boolean (true or false) value (the relevant variable should be of the int type). The invbool type reverses the value, so the true value is false, and vice versa.

CHARP

One character pointer value. The memory is allocated to strings provided by the user, so the pointer is set.

Int

Long

Short

Uint

Ulong

Ushort

Basic variable-length integer value. The value starting with u is an unsigned value.

Array parameter, the value provided by the list separated by commas (,). The module loader also supports. Declare an array parameter, using:

module_param_array(name,type,num,perm);

Here, name is the name of your array (also the parameter name), type is the type of the array element, num is an integer variable, and perm is the common permission value. if the array parameter is set during loading, num is set to the number of provided numbers. the module loader rejects more values than the array can put down.

If you need a type that does not appear in the list above, hooks in the module code will allow you to define them. For details about using them, see moduleparam. h. all module parameters should be given a default value; insmod changes these values only when the user explicitly notifies it. the module can check obvious parameters and check these parameters by their default values.

The last module_param field is a permission value. You should use <Linux/STAT. h>. this value controls who can access the representation of these module parameters in sysfs. if perm is set to 0, there is no sysfs entry at all. otherwise, it appears under/sys/module [5] with the given permissions. the s_irugo parameter can be read by all users,
But it cannot be changed; s_irugo | s_iwusr allows root to change the parameter. note: If a parameter is modified by sysfs, the parameter value you see in your module also changes, but your module has no other notifications. you should not make module parameters writable unless you are ready to detect this change and respond accordingly.