Turn Linux device model (4)

Wwang
Source: Http://www.cnblogs.com/wwang
This article uses the Creative Commons Attribution-Non-commercial use-the same way to share 2.5 Chinese mainland License Agreement license, welcome reprint, but without the consent of the author must retain this paragraph statement, and in the article page obvious location to give the original text connection.

The Linux device Model (2) and the Linux device Model (3) mainly introduce the usage of Kobject, Kset, Kobj_type, attribute and other data structures through some simple implementation. However, these practices do not involve the equipment model and SYSFS in the real environment. This article will take the module subdirectory under/sys as an example to see how the kernel constructs the Sysfs tree.

(Note: This analysis is based on the 2.6.36 kernel)

Creation of module

When module is insmod to kernel space, a directory with the same name as the module is created in the/sys/module directory. We take usb_storage as an example, after executing the sudo modprobe usb_storage, SYSFS will produce a directory named Usb_storage, whose directory structure is:

In the Linux 2.6 kernel, the module's insertion is initiated by the user program Insmod (modprobe is ultimately called Insmod), but most of the work is done by the kernel. We can use Strace to look at 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 insmod, when executed, will first map the contents of the module to memory, and then call the system to call Init_module to achieve real work.

As shown, this is the execution path of the system call Init_module. Because this article only discusses the device model and SYSFS, the flowchart involves only relevant content.

1, Mod_sysfs_init First will query the current module (in this case, usb_storage) in Sysfs whether it already exists, if not, call Kobject_init_and_add created;

2. Call Kobject_create_and_add to create the holders directory. The holders directory is used to store links to other module, where the other module is dependent on the current module. Take Usb_storage as an example, if we need to use UMS_XX modules (such as Ums_karma or ums_freecom, etc.), you can call sudo modprobe ums_xx to complete the load, because UMS_XX relies on usb_storage, So in the Usb_storage/holders directory will create a link to ums_xx, while refcnt will add 1;

3, Module_param_sysfs_setup used to create the parameters directory, the file in this directory corresponds to all parameters of the current module. In the Linux kernel, the __param section of the module's binary ko file is used to store the parameters of the current module, and Load_module reads the parameters into the memory structure MODULE_PARAM_SYSFS_ Setup then creates the Paramters directory and its parameter files according to the corresponding structure;

4. Module_add_modinfo_attrs is used to create 4 files in the current module directory: version, Srcversion, refcnt, and Initstate, where 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 there is no version of this file. By the way, in the Linux kernel, you can use the macro module_version to define the version number, such as Module_version ("v1.00") definition version number is v1.00, where the version information is completely a string, and no specific format. Srcversion can be defined by Module_info (srcversion, XXX), but is normally generated by the Modpost by default. Refcnt reflects the reference count of the current module. Initstate reflects the three states of module: Live, coming, and going;

5, Add_usage_links and holders are closely related, but this function is not the holders directory to manipulate the current module. Take Ums_xx as an example, in the ums_xx loading process, its add_usage_links will add themselves as a link to usb_storage holders directory;

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. It should be recalled that the naming of sections is usually "." Start with "." The beginning of the file in Linux is considered to be hidden files, so if you want to see the LS command after adding "-a" parameter, the following notes also need to deal with this;

7. Add_notes_attrs is used to create the notes directory. The elf file format defines an element called note, which is used primarily to add some markup information to a binary file. In general, we can use readelf to see if the elf file contains a note section. For example Usb_storage, we can use the command "Readelf Usb-storage.ko-n" to see its output as follows:

Notes at offset 0x00000034 with length 0x00000024:

Owner Data Size Description

GNU 0x00000014 nt_gnu_build_id (unique BUILD ID bitstring)

Accordingly, the notes file created under the/sys/module/usb_storage/notes directory is. Note.gnu.build-id.

In the above 7 process, there is no place to create drivers, that/sys/module/usb_storage under the drivers directory is how to build it? The answer is:

In Usb_storage's Module_init, Usb_register is called to register the usb_driver structure, as shown in the final call to Module_add_driver to create the drivers directory.

The revocation of module

Module revocation process and the previous article in the creation process one by one corresponding, here is not described in detail, please see.

About the creation and revocation of other subdirectories in Sysfs, we can easily find the corresponding code in the Linux kernel, this article no longer one by one repeat.

Turn Linux device model (4)