Linux core -- 13. Linux dynamic module

Article title: Linux core-13. Linux dynamic module. Linux is a technology channel of the IT lab in China. Includes basic categories such as desktop applications, Linux system management, kernel research, embedded systems, and open source.
By: David A Rusling
Translation: Banyan & fifa
Chapter 4 modules
　　
This chapter describes how Linux core dynamic loading function modules (such as file systems) work.
Linux core is a monolithic kernel, that is, a single large program. all functional components in the core can access all its internal data structures and routines. Another form of the core is the microkernel structure. at this time, all functional components of the core are split into independent parts, which are linked through strict communication mechanisms. It takes a lot of time to add new parts to the core by configuring the process. For example, we want to configure a SCSI driver for an NCR 810 scsicard, but this is not part of the core. Then we must reconfigure and reconstruct the core. Linux allows us to dynamically load and detach operating system components at will. The Linux module is such a code block that can dynamically connect to the core at any time after the system is started. When we no longer need it, we can detach it from the core and delete it. A Linux module is a device driver or pseudo-device driver, such as a network device or a file system.
　　
Linux provides two commands for us: using insmod to explicitly load the core module, and using rmmod to uninstall the module. At the same time, the core itself can also request the core background process kerneld to load and uninstall the module.
　　
The advantage of dynamic code loading is that the core can be kept small and flexible. In my Intel system, because of the use of modules, the entire core is only kb long. Because I only occasionally use the VFAT file system, I construct a Linux core to automatically load the VFAT file system module when mount VFAT partitions. When I detach a VFAT partition, the system will detect that I no longer need the VFAT file system module and detach it from the system. The module also allows us to try to run the new core code without restructuring the core and restarting it frequently. Despite the free use of modules, it may also cause performance and memory loss related to core modules. Code of the loadable module is generally long and the extra data structure may occupy some memory. At the same time, indirect use of core resources may cause some efficiency problems.
　　
Once a Linux module is loaded, it is also a core part of common core code. They have the same permissions and responsibilities as other core code; in other words, the Linux core module can crash the core like all core code and device drivers.
　　
To use the required core resources, the module must be able to find them. For example, the module needs to call the core memory allocation routine kmalloc () to allocate memory. The module does not know where kmalloc () is in the memory during construction. Therefore, the core must modify the reference address of kmalloc () in the module before using these modules. The core maintains a linked list of core resources in its core symbol table, so that when a module is loaded, it can parse references to core resources in the module. Linux also allows the existence of a module stack, which is used for inter-module calls. For example, the VFAT file system module may need the service of the FAT file system module, because the VFAT file system is extended from the FAT file system. The requirement of a module for services or resources of other modules is similar to that of a module for core resources or services. However, the requested service comes from another previously loaded module. When a module is loaded, the core adds all the resources and symbols output by the newly loaded module to the core symbol table.
　　
When trying to uninstall a module, the core needs to know whether the module is not in use, and it needs a way to notify this module to uninstall. The module must be able to release all its allocated system resources, such as core memory or interrupt, before deleting from the core type. When a module is detached, the core deletes all corresponding symbols from the core symbol table.
　　
The ability to load modules can crash the operating system. However, writing poor modules poses another problem. What will happen when you load a module on a core that is constructed either early or late, instead of the core that you are currently running? One possible scenario is that the module calls a core routine with incorrect parameters. The core should use strict version control to check the loading module to prevent this situation.
12.1 module loading
2.1 Core Module linked list s
The core module can be loaded in two ways. First, use the insmod command to manually load the module. The other is to load the module as needed; we call it request loading. When the core finds it necessary to load a module, if the user installs a file system that does not exist in the core, the core will request the core background process (kerneld) to prepare to load the appropriate module. This core background process is only a common user process with super user permissions. When the system is started, it is also started and opens an inter-process communication (IPC) channel for the core. The core uses it to send messages to kerneld when executing various tasks. The main function of kerneld is to load and uninstall the core module, but it can also execute other tasks, such as establishing a PPP connection through a serial line and disabling it as appropriate. Kerneld itself does not execute these tasks. It does this through some programs such as insmod. It is only the core proxy and scheduling for the core.
　　
The insmod program must find the core module to be loaded. The request loading core module is generally stored in/lib/modules/kernel-version. These core modules are connected to target files like other programs in the system, but they are connected to a relocated image. That is, the image is not connected to a specific address. These core modules can be in a. out or ELF file format. Insmod executes a privileged system call to find the core output symbol. These are saved in pairs by symbol names and numerical values, such as address values. The core output symbol table is saved in the first module structure of the module linked list maintained by the core, and the module_list pointer points to this structure. Only special symbols are added to this table. they are determined during core compilation and connection, and not each symbol of the core is output to its module. For example, a device driver uses the "request_irq" symbol called by the core routine to control the interruption of a specific system. In my system, the value is 0x0010cd30. You can use the ksyms tool or view/proc/ksyms to view the current core output symbol. The ksyms tool displays both the core output symbols and the loaded modules. Insmod reads the module into the virtual memory and uses the core output symbol to modify its unresolved core routines and resource reference addresses. These modifications take the insmod program to directly write the symbolic address to the corresponding address in the module to modify the module image in the memory.
　　
After insmod modifies the module's reference to the core output symbol, it will use the privileged system call again to apply for sufficient space to accommodate the new core. The core allocates a new module structure and enough core memory for it to save the new module, and puts it at the end of the core module linked list. Then mark the new module as UNINITIALIZED.
　　
2.1 provides a core linked list for loading two modules: VFAT and FAT. However, the figure does not show the first module in the linked list: a pseudo module used to store the core output symbol table. Lsmod can help us list all the loaded core modules in the system and their dependencies. It does this by reformatting the/proc/modules created from the core module structure. The memory allocated by the core is mapped to the insmod address space so that it can access the core space. Insmod copies the module to the allocated space. if the allocated core memory is used up, it applies again. However, do not expect to load modules to the same address multiple times, not to mention the same location in two different Linux systems. In addition, this relocation includes modifying the module image using the appropriate address.
This new module also hopes to output its symbols to the core, and insmod will construct an output symbol image table for it. Each core module must contain module initialization and module clearing routines. their symbols are designed to be intentionally not output, but insmod must know these addresses so that they can be passed to the core. After all this work is done, insmod will call the initialization code and execute a privileged-level system call to pass the module's initialization and clearing routine address to the core.
　　
When a new module is loaded into the core, the core must update its symbol table and modify the old modules used by the new module. Modules dependent on other modules must maintain a reference linked list at the end of the symbol table and point to it in the module data structure. In 2.1, VFAT depends on the FAT file system module. Therefore, the FAT module contains a reference to the VFAT module. This reference is added when the VFAT module is loaded. The initialization routine of the core call module. if successful, it will install this module. The address of the clearing routine of the module is stored in its module structure, which will be called by the core when the module is detached. The final module status is set to RUNNING.
12.2 uninstall the module
The module can be deleted by using the rmmod command, but the request loading module will be automatically deleted from the system when kerneld's usage count is 0. Kerneld executes a system call every time its idle timer expires to delete all unused request loading modules from the system. The value of this timer is set when kerneld is started; the value on my system is 180 seconds. In this way, if you install an iso9660 CDROM and your iso9660 file system is a loadable module, the iso9660 module will be deleted from the core within a short time after the cd rom is detached.
　　
If another part of the core is still using a module, the module cannot be uninstalled. For example, if multiple VFAT file systems are installed in your system, you cannot uninstall the VFAT module. Execute lsmod and we will see the reference count for each module. For example:
　　
Module: # pages: Used:
Msdos 5 1
Vfat 4 1 (autoclean)
Fat 6 [vfat msdos] 2 (autoclean)
　　
This note indicates the number of core entities dependent on this module. In the above example, both the VFAT and msdos modules depend on the fat module, so the reference count of the fat module is 2. The reference records of the vfat and msdos modules are 1, indicating that each of them has an installed file system. If we install another VFAT file system, the reference count of the vfat module is 2. The reference records of the module are stored in the first long word of the image. This word also contains the AUTOCLEAN and VISITED flags. The request loading module uses these two flag fields. If the module is marked as AUTOCLEAN, the core knows that the module can be automatically detached. The VISITED flag indicates that this module is being used by one or more file systems. this flag is set as long as other parts use this module. Each time the system is asked by kerneld to delete a request module that is not used by anyone, the core will scan all modules for possible candidates. However, you can only view the modules marked as AUTOCLEAN and RUNNING. If the VISITED mark of a module is cleared, it is deleted. If a module can be detached, you can call its clearing routine to release the core resources allocated to it. The module structure corresponding to it will be marked as DELETED and disconnected from the core blockchain table. Other modules dependent on it modify their respective reference domains to indicate that the dependencies between them no longer exist.