Linux Device Model (4)

Linux Device Model (2) and Linux Device Model (3) mainly introduce the usage of data structures such as kobject, kset, kobj_type, and attribute through some simple practices, however, these implementations do not involve the device models and sysfs in the actual environment. This article takes the module subdirectory under/sys as an example to see how the kernel builds the sysfs tree.

(Note: The analysis in this article is based on the 2.6.36 kernel)

 

Module Creation

When the module is insmod to the kernel space, a directory with the same name as the module is created under the/sys/Module Directory. Take usb_storage as an example. After executing sudo modprobe usb_storage, sysfs will generate a directory named usb_storage. Its directory structure is:

In the Linux 2.6 kernel, module insertion is initiated by the user program insmod (modprobe is also called insmod), but most of the work is still done by the kernel. We can use strace to observe the insmod process.

Stat64 ("/sys/module/usb_storage", 0xbfb9a654) =-1 enoent (no such file or directory)
Open ("/lib/modules/2.6.35-24-generic/kernel/Drivers/USB/storage/usb-storage.ko", o_rdonly) = 3
Fstat64 (3, {st_mode = s_ifreg | 0644, st_size = 94776,...}) = 0
Mmap2 (null, 94776, prot_read | prot_write, map_private, 3, 0) = 0xb776f000
Close (3) = 0
Init_module (0xb776f000, 94776, "") = 0
Munmap (0xb776f000, 94776) = 0
Exit_group (0) =?

From this process, we can see that during insmod execution, the module content is first mapped to the memory, and then the system calls init_module to implement real work.

As shown in, this is the execution path of the System Call init_module. Because this article only discusses the device model and sysfs, the flowchart only involves the relevant content.

1. mod_sysfs_init first queries whether the current module (in this example, usb_storage) already exists in sysfs. If not, call kobject_init_and_add to create it;

2. Call kobject_create_and_add to create the holders directory. The holders directory is used to store links to other modules. Other modules here depend on the current module. Take usb_storage as an example. If we need to use the ums_xx module (such as ums_karma or ums_freecom), we can call sudo modprobe ums_xx to complete the loading, because ums_xx depends on usb_storage, therefore, in the usb_storage/holders directory, a link pointing to ums_xx will be created, and refcnt will also add 1;

3. module_param_sysfs_setup is used to create the parameters directory. The files in this directory correspond to all parameters of the current module. In the Linux kernel, the _ Param section in the module binary Ko file is used to store the parameters of the current module. load_module reads these parameters into the memory structure, module_param_sysfs_setup then creates the paramters directory and Its Parameter files based on the corresponding structure;

4. module_add_modinfo_attrs is used to create four files in the current Module Directory: version, srcversion, refcnt, and initstate. The version and srcversion information is stored in the. modinfo section of the binary Ko file. For the usb_storage module, version is not specified, so the file version does not exist. By the way, in the Linux kernel, you can use the macro module_version to define the version number. For example, module_version ("v1.00") defines the version number as v1.00. The version information here is completely a string, no specific format. Srcversion can be defined by module_info (srcversion, XXX), but it is generally generated by modpost by default. Refcnt indicates the reference count of the current module. Initstate indicates three States of the module: Live, coming, and going;

5. add_usage_links and holders are closely related, but this function is not used to operate the holders directory of the current module. Taking ums_xx as an example, during the ums_xx loading process, its add_usage_links will add itself as a link to the holders directory of usb_storage;

6. The sections directory corresponds to the Section information in the binary Ko file of the current module, which is implemented through add_sect_attrs. Note that the section name is usually ". starting with ". "files starting with" are considered as hidden files in Linux, so if you want to view them, add the "-a" parameter after the LS command. The notes mentioned below also needs to be processed like this;

7. add_notes_attrs is used to create the notes directory. The ELF File Format defines an element named note, which is mainly used to add some identification information to the binary file. In general, we can use readelf to check whether the ELF file contains the note section. For example, usb_storage, we can use the command "readelf usb-storage.ko-n" to view, the output is as follows:

Notes at offset 0x00000034 with length 0x00000024:

Owner data size description

GNU 0x00000014 nt_gnu_build_id (unique build ID bitstring)

Correspondingly, the notes file created under the/sys/module/usb_storage/Notes directory is. Note. GNU. Build-id.

 

No drivers is created in the above seven procedures. How is the DRIVERS directory created under/sys/module/usb_storage? The answer is:

 

In module_init of usb_storage, usb_register is called to register the usb_driver structure. As shown in, module_add_driver is called to create the DRIVERS directory.

 

Module Revocation

The module revocation process corresponds to the creation process in the previous article, which is not described in detail here. Please refer.

 

 

For the creation and revocation of other sub-Directories In sysfs, you can easily find the corresponding code in the Linux kernel.