Modules describes how Linux core only load functions only when needed, such as a file system. Linux is a complete core, that is, it is a single huge program that can access all of its internal data structures and routines. Another method is to use a micronard structure, the core functional piece is divided into independent units, and there is a strict communication mechanism between each other. This increases the new component to the core by configuring the process. For example, you want to add an NCR 810 SCSI card's SCSI driver, you don't need to connect it to the core. Otherwise you have to configure and build a new core to use this NCR 810. As a variant, Linux allows the components of the operating system to be dynamically loaded and uninstalling when you need. The Linux module is a code block that can be dynamically connected to the core after the system starts. They can delete and uninstall from the core when it is not required. Most Linux core modules are device drivers, pseudo-devices drivers such as network drivers or file systems. You can use the insmod and rmmod commands to explicitly load and uninstall the Linux core module, or when these modules are needed, they require the core daemon (kernel) to load and uninstall these modules. Dynamically load the code is quite attractive when needed because it allows the core to remain minimal and the core is very flexible. My current Intel core uses modules, it is only 406K size. I usually only use the vfat file system, so I build my Linux core, and automatically load the VFAT file system when I install a VFAT partition. When I uninstall the VFAT file system, the system detects that I no longer need a vfat file system module and remove it from the system. The module can also be used to try new core code without having to create and restart the core each time. However, there is no such thing, using the core module usually accompanied by slight performance and memory spending. A loadable module must provide more code, this code and additional data structures take up more memory. In addition, the module is slightly lowered because indirect access core resources also make the modules. Once Linux core loading, it becomes a part of the core as the normal core code. It has the same rights and obligations as any core code: in other words, the Linux core module and all core code or device drivers can make the core crash. Since the module can use core resources when needed, they must be able to find these resources. For example, a module needs to call Kmalloc (), the core memory allocation routine. When it is created, the module does not know where the memory kmalloc () is, so when this module is loaded, the core must organize all the references to kmmalloc () before the module is capable of work. The core saves a list of all core resources in the core symbol table, so it can parse references to these resources when the module is loaded. Linux allows the module stack (stacking), just a module that requires another module service. For example, the VFAT file system module requires a service of the FAT file system module because the VFAT file system is more or less extension on the FAT file system. A module requires a service or resource of another module and a module that requires the core of your own service and resources. It is only the service that the request is in the other, the module clock that has been loaded. When each module is loaded, the core modifies its symbol table, add all the outputs of this newly loaded module to the core symbol table. This means that when the next module is loaded, it can access the service that has been loaded. When the picture uninstalls a module, the core needs to know that this module is not in use, it also needs some way to inform it to prepare the uninstalled module.
This method module can be used to release any system resources it occupied from the core, such as core memory or interrupts. When the module is uninstalled, the core outputs this module to all symbols in the core symbol table. In addition to writing bad loadless modules, there may be another danger. What happens if you load a module established for the core that is earlier than your current run? If this module performs a core routine, it will cause a problem. The core can choose to prevent this, and perform a strict version check when the module is loaded. 12.1 Loading a Module Use two ways to load a core module. The first kind of inSmod command manually puts it into the core. The second, smarter method is to load this module when needed: this is called Demand Loading. When the core finds a module, for example, when the user installs a file system that is not at the core, the core will request the core daemon (kernel) attempt to load the appropriate module. Kerneld and Insmod, LSMOD, and RMMOD are in the Modules package. The core daemon is usually a general user process with superuser privileges. When it starts (typically starting when the system is started), it opens an IPC channel to the core. The core uses this connection to the Kerneld to send a message, requesting it to perform a large number of tasks. The main function of Kerneld is to load and uninstall the core module, but it can also perform other tasks, such as starting a PPP connection on the serial line when needed, and shuts down when it is not required. Kernel itself does not perform these tasks, which runs the necessary programs such as INSMOD to complete work. Kerneld just a nuclear agent dispatched its work. See the include / linux / kerneld.hinsmod command must find the requested core module to be loaded. The core modules that press Xu usually are usually placed in the / lib / mmodules / kernel-version directory. The core module and other programs in the system are the target files of the connection program, but they are connected to an image that can be relocated. There is not an image that is not connected to a specific address. They can be a target file in a.out or ELF format. InSmod points to a privileged system call to find out the output symbol of the system. They are stored in the form of a symbol name and value (eg, its address). The core output symbol table is placed in the first Module data structure in the module list of core maintenance, pointing to the module_list pointer. Only the special specified symbols in the core compilation and connections are added to this table, while each symbol is not the core outputs its module. For example, symbol "request_irq" is a system routine that must call it when a driver wants to control a particular system interrupt. On my current core, its value is 0x0010cd30. You can check file / proc / ksyms or simply view the core symbols of the output using the Ksyms tool and their values. Ksyms tools can display all of the core symbols of all outputs or only symbols of which load modules output. Insmod reads the module to its virtual memory, use the core output symbol to organize this module for unresolved references for core routines and resources. This sorting process is performed in a way that patch the module image in memory, and INSMOD physically writes the address of the symbol to the appropriate position of the module. See kernel / module.c kernel_syms () include / linux / module.h When INSMOD finishes the module for the core symbol of the output, he places a new core to the core request, and the privilege is called. The core assigns a new Module data structure and sufficient core memory to store this new module and place it to the core of the core module list.
This new module is marked uninitialized. Figure 12.1 shows two modules of the core module list: FAT and VFAT are loaded to memory. The first module of the list is not displayed in the figure: This is a pseudo module for placing the core output symbol table. You can use the command lsmod to list all loaded core modules and the dependencies between them. LSMOD simply rearranges the formatted / proc / modules extracted from the core Module data structure list. The core is an address space that is allocated by the module to the address space of the Insmod process, so it can access it. INSMOD copies the module to the assigned space and relocates it so that it can run from the assigned core address. Relocation must be performed because one module cannot be expected to be loaded to the same address or on two different Linux systems. This time, the relocation is related to the image to make the image to be used as the module. See the kernel / module.c create_module () new module also establishes an output image table to the core output symbol, INSMOD. Each core module must contain module initialization and module clearance. These symbols must be dedicated rather than output, but Insmod must know their address and can pass them to the core. After all of this, INSMOD is now ready to initialize this module, which performs a privilege system call, passes the address of this module's initialization and clerution routine to the core. See kernel / module.c sys_init_module () When a new module adds to the core, it must update the core symbol table and change the module used by the new module. Other modules dependent the module must maintain a reference list after their symbol table, point to their module data structure. Figure 12.1 shows the VFAT file system module depends on the FAT file system module. So the FAT module contains a reference to the VFAT module: This reference is increased when the VFAT module is loaded. The initialization routine of the core call module, if successful, it starts to install this module. The address of the module clearance routine is saved in its Module data structure, and the core will call when this module is uninstalled. Finally, the state of the module is set to Running. 12.2 Unloading a Module Module You can use the RMMOD command to delete, but Kerneld can remove all the modules loaded on-demand from the system from the system. When it expires each time it expires, the kernel has executes system calls, requests all unwanted on-demand loads from the system. The value of this timer is set by you when starting KERNELD: My kernel is checked once every 180 seconds. If you have an ISO9660 CD ROM and your ISO9660 file system is a loaded module, then the ISO9660 module is removed from the core in the CD ROM uninstallation. If other components in the core depend on a module, it cannot be deleted. For example, if you have one or more VFAT file systems, you cannot uninstall the VFAT module. If you check the LS output, you will see that each module is associated with a counter. For example: Module: #pages: Used by: MSDOS 5 1VFAT 4 1 (Autoclean) FAT 6 [VFAT MSDOS] 2 (count) This counter is dependent on the number of core entities of this module. In the above example, both vfat and msdos rely on the FAT module, so the counter of the FAT module is 2. The dependent number of VFAT and MSDOS modules is 1 because they have a file system installed.
