[Translation] 5.5. Initialization options initialization options

Directory: http://www.cnblogs.com/WuCountry/archive/2008/11/15/1333960.html
 
[Do not provide illustrations. You are advised to download the source book from the Internet]

5.5. Initialization options initialization options
Both components built into the kernel and components loaded as modules can be passed input parameters so that users can fine-tune the functionality implemented by the components, override defaults compiled into them, or change them from one system boot to the next. the kernel provides two kinds of macros to define options:
You can input parameters to adjust the functions provided by the components, whether compiled into the kernel or loaded in the form of modules. Reload the default values compiled into the component, or modify them when the system starts later. The kernel provides two macro-defined options:

Module options (macros of the module_param family)
Module option module_param family macro

These define options you can provide when you load a module. when a component is built into the kernel, you cannot provide values for these options at kernel boot time. however, with the introduction of the/sys filesystem, you can configure the options via those files at runtime. the/sys interface is relatively new, compared to the/proc interface. the later section "module options" goes into a little more detail on these options.
When you load a module, You can provide these definition options. When a component is compiled to the kernel, you cannot provide values for these components when the kernel is started. However, by introducing the/sys file system, you can configure these options through these files at runtime. Compared with the/proc interface, the/sys interface is a new method. In the next section, "module options" will further discuss these options.

Boot-Time Kernel options (macros of the _ setup family)
Kernel options at startup (_ seup family macro)

these define options you can provide at boot time with a boot loader. they are used mainly by modules that the user can build into the kernel, and kernel components that cannot be compiled as modules. you will see those macros in the section "boot-Time Kernel options" in Chapter 7.
you can use bootloader to provide these definition options when the kernel is started. These are mainly used by those users to compile modules into the kernel, and those kernel components that can be compiled into modules. You will see these macros in Chapter 7th "kernel options at startup.

it is interesting to note that a module can define an initialization option in both ways: one is always tive when the module is built-in and the other is always tive when the module is loaded separately. this can be a little confusing, especially because different modules can define passing parameters of the same name at module load time without any risk of name collision (I. E ., the parameters are P Assed just to the module being loaded), but if you pass those parameters at kernel boot time, you must make sure there is no name collision between the various modules 'Options.
it is worth noting that when a module can define an initialization option in two ways: one is to take effect at the time of compilation, and the other is to take effect when the module is loaded independently. This may be confusing, especially because different modules can be defined as parameters with the same name during loading without any risk of Name Conflict (for example, these passed parameters are only used for module loading), but if you pass these parameters at kernel startup, you must ensure that these parameter names do not conflict with the module options.

we will not go into detail on the pros and cons of the two approaches. you can look at the drivers/block/loop. c driver for a clear example using both module_param and _ setup.
we will not discuss the prod and codns methods in detail. You can see detailed driver examples in drivers/block/loop. C. They use module_param and _ setup.