20150225 IMX257 Device Driver Model Sysfs file system knowledge Point integration (II.)

20150225 IMX257 Device Driver Model Sysfs file system knowledge Point integration (II.)

2012-02-25 Li Hai along

The day before yesterday we realized a simple Sysfs kobject driver, but did not find a lot of things do not understand, the reason is that in our work on SYSFS and Kobject do not understand, although I have been not advocating all day contact with those boring knowledge points, also has not liked to talk about too much knowledge points , but sometimes, theoretical knowledge is the basis of practice, some basic knowledge points still have to mention, the following into the topic.

I. Introduction of SYSFS

After the linux2.6 kernel, introduced a new file system Sysfs, which is attached to the/sys directory, like Devfs It is also a virtual file system, is also used to manage the system's equipment, it is actually connected to the system of equipment and bus organized into a hierarchical file, User-space programs can also use this information to implement the interaction with the kernel, the filesystem is an intuitive response to the actual device tree on the current system, which is built through the Kobject subsystem, and when a kobject is created, the corresponding files and directories are created, located/ SYS under the relevant directory, since each device in the SYSFS has a unique corresponding directory, then it can be read and write user space. The tool udev for user space uses the information provided by SYSFS to implement all DEVFS functions, but the difference is that Udev runs in user space, while DEVFS is running in kernel space, and Udev does not have devfs congenital flaws. It is clear that SYSFS will be the direction of future development.

Sysfs the device and bus connected to the system into a hierarchical directory and file, which can be accessed by user space, the kernel data structure and their attributes are exported to user space, including the primary and secondary device number of the device. The new device file system Udev's work process relies on these features of the Sysfs file system. The Udev file system works in user space, and it can dynamically create and delete device files based on information derived from the Sysfs file system (device number (dev), etc.) without the need to manually build the device files using Mknod. You do not have to worry about finding the device number, especially the device number that is generated by the dynamic request in the driver.

The Kobject Kernel object provides basic object management capabilities, is the core structure of the Linux 2.6 device model, and each Kobject object registered in the kernel corresponds to a directory of the Sysfs file system, which can be implemented through the following function calls:

Kobject_add (), Kobject_add_varg (), kobject_add_internal (), Create_dir (), Sysfs_create_dir ()

SYSFS all directories under the file system, the final process is achieved by registering to add Kobject to the Linux device hierarchy, for two examples:

1.class Catalog

Kobject_add_internal, Kset_register, Class_register, __class_register,

2.device Catalog

Device_register, Device_add, Kobject_add

Therefore, for a device that is not a file under the Sysfs file system, but a directory, the source of the directory name is the name field of the Kobject object. There will be two files and several directories in the directory, and these two files are the properties files of the device. We can look at the implementation of the Device_add function, which includes:

912 error = Device_create_file (dev, &uevent_attr); Create a property file 913 if (Error) 914 goto Attrerror; 915 916 if (MAJOR (dev->devt)) {//Read the device's main device number 917 error = device_create_file (dev, &devt_attr); Write the device number related properties file 918 if (Error) 919 Goto Ueventattrerror;

From the above program, we will create two properties files in the corresponding device directory of the Sysfs file system.

Let's look at what these two structures are like, uevent_attr and Devt_att.

311 static struct Device_attribute uevent_attr = 312 __attr (uevent, S_irugo | S_IWUSR, show_uevent, store _uevent); 428 static struct Device_attribute devt_attr = 429 __attr (Dev, S_irugo, Show_dev, NULL);

And look at _attr:

#define __ATTR (_name,_mode,_show,_store) { attr = {. Name = __stringify (_name),. Mode = _mode}, \ Show = _show, \ Wuyi store = _store, \ 52}

Can be found, translation, in fact, we Uevent_att property is:

Static struct Device_attribute uevent_attr = { . attr = { . Name = uevent,//device property file name . Mode = S_irugo | S_IWUSR,//Permissions } . Show = Show_uevent,//Read device properties file . store = store _uevent,//write device properties file }

Similarly, we can also get the structure of devt_attr:

Static struct Device_attribute devt_attr = { . attr = { . Name = Dev,//device property file name . Mode = S_irugo,//Permissions } . Show = Show_dev,//Read device properties file . store = NULL, }

The corresponding read and write operations, but the reading and modification of these properties.

Ii. introduction of Udev

Udev is a feature in the Linux2.6 kernel that replaces the original DEVFS and becomes the current Linux default device management tool. Udev runs as a daemon, managing the device files under the/dev directory by listening for the uevent that are issued within it. Unlike previous device management tools, Udev runs in user space instead of kernel space (kernel spaces).

Let's look at how Udev can create device nodes from SYSFS.

For drivers that have been programmed into the kernel, the objects are registered directly in the SYSFS when detected by the kernel, and for drivers that are compiled into modules, this is done when the module is loaded. Once the Sysfs file system is mounted (mounted to/sys), the built-in driver can be used by the user-space process and provided to Udev to create the device node in SYSFS registered data.

The Udev initialization script is responsible for creating a device node at Linux startup, which first registers/sbin/udevsend as a hot-swappable event handler. Hot-Plug events (which are discussed later) should not have happened at this stage, and the Udev was registered just in case. The Udevstart then traverses the/sys file system (which records the device's main device number and the secondary device number in its properties file dev) and creates a description-compliant device file in the/dev directory. For example,/sys/class/tty/vcs/dev contains a "7:0" string, and Udevstart creates a/DEV/VCS device with the main device number 7 and the second device number 0 based on the string. The name and permissions of each device created by Udevstart are set by the rules specified by the files in the/etc/udev/rules.d/directory. If Udev cannot find a permission file for the device that was created, it sets its permissions to the default of 660, and the owner is root:root.

When the above steps are complete, the devices that already exist and have built-in drivers are ready to use, what about the module-driven devices?

Most Linux distributions handle module loading through the/etc/modules.conf configuration file, and access to a device node causes the corresponding kernel module to be loaded. This approach to Udev does not work because the device node does not exist before the module is loaded. To solve this problem, a modules startup script was added to the Lfs-bootscripts software package, and

/etc/sysconfig/modules file. By adding the module name to the modules file, the modules can be loaded at system startup so that Udev can detect the device and create the appropriate device node. If the plugged-in device has a driver module but has not yet been loaded, the Hotplug package will be useful, and it will respond to the above kernel bus-driven hot-plug events and load the appropriate modules to create device nodes for them so that the device can be used.

Udev is a tool that dynamically updates device files based on the state of the hardware devices in the system, including the creation, deletion, etc. of the device files. Device files are usually placed in the/dev directory, and after using Udev, only the devices that are actually present in the system are included under/dev. It is independent of the hardware platform, is located in the user space, needs the support of kernel Sysfs and TMPFS, SYSFS provides the device entrance and Uevent channel for Udev, and TMPFS provides storage space for udev device files.

Advantages of the easy-to-see Udev device files:

1.udev works entirely in the user state, using the hot-swap events sent by the kernel when the device is added or removed. When hot-swappable, the device details are output by the kernel to the/sys Sysfs

File system. Udev's device naming policy permission control is done in the user state, and it uses SYSFS information to create a device file node.

2.udev dynamically update the device files according to the status of the hardware devices in the system, create and delete the device files, etc.

Note: Using the Udev,/dev directory will contain only the devices that really exist in the system.

3. Dynamic management: When the device is added/removed, the Udev daemon listens to uevent from the kernel to add or remove device files from/dev, so udev only generates device files for connected devices without generating a large amount of empty device files in/dev.

4. Custom naming rules: through the Linux default rules file, Udev defines the kernel device names for all devices in/dev/, such as/DEV/SDA,/dev/hda,/DEV/FD, and so on. Because Udev is running in user space, Linux users can flexibly produce highly identifiable device filenames, such as/dev/boot_disk,/dev/root_disk,/dev/color_, through custom rules files. Printer and so on.

5. Set permissions and owners/groups for the device: Udev can set the permissions of the device files and the device file owner/group according to certain conditions. In different udev versions, the methods are implemented differently and are explained in "How to configure and use Udev."

Note: All devices displayed in Sysfs can be created by Udev to create a node. If the kernel adds support for other devices,

Udev will automatically be able to work with them. Before Init initialization, Udev can be put into INITRAMFS and run when each device is discovered.

It is also possible for Udev to work within the initial/dev directory created by/sys content after a real root partition has been loaded

Work flow

Iii. introduction of DEVFS

Linux has a dedicated file system for the management of devices, DEVFS and Sysfs are two of them.

The 2.6 kernel used to be DEVFS,DEVFS mounted in the/dev directory, providing a file-like way to manage all the devices located in the/dev directory, we know that each file in the/dev directory corresponds to a device, as to whether the device is present or not, And these special files are located on the root file system, we have built these device files when we make the file system, so by manipulating these special files, we can interact with the kernel.

However, the Devfs file system has some drawbacks, such as: Uncertain device mappings, sometimes a device mapping device files may be different, for example, my USB flash drive may correspond to the SDA may correspond to SDB, there is not enough primary/secondary device number, when the device is too large, it is obvious that this will become a problem;/dev Directory There are too many files and cannot represent the actual devices on the current system, the names are not flexible enough to be arbitrarily specified, and so on.

Iv. comparison between Udev and DEVFS equipment files

The 1.udev enables all DEVFS implementations. But Udev runs in user mode, while DEVFS runs in the kernel.

2. When a/dev node that does not exist is opened, DEVFS automatically loads the driver and Udev does not. Udev is designed to load a module when the device is discovered, rather than when it is accessed.

Devfs This feature is redundant for a properly configured computer. All devices in the system should generate HotPlug events, load appropriate drivers, and Udev will take note of this and create corresponding device nodes for it.

If you don't want all of your device drivers to stay in memory, you should use something else to manage your modules (such as scripts, modules.conf, and so on).

The Devfs method led to a large number of useless modprobe attempts to detect the existence of the device.

Each exploratory probe creates a new process to run modprobe, and almost all of this is useless.

3.udev is achieved by adding aliases to the device names generated by the kernel. As mentioned earlier, Udev is a user-mode program that does not change the behavior of the kernel.

As a result, the kernel will continue to produce device names such as Sda,sdb. However, Udev can differentiate different devices and produce device files based on other information, such as bus, manufacturer (vendor), and other devices. Udev can solve this problem by simply taking a fixed file name for the device file. In subsequent operations on the device, simply refer to the new device name. But in order to ensure maximum compatibility, in general, the new device name is always used as a symbolic link to the device name automatically generated by the kernel.

For example: The kernel generated the SDA device name, and according to the information, this device corresponds to my internal hard drive, then I can make udev rules, so that udev in addition to generating/DEV/SDA device files, in addition to create a symbolic link called/DEV/INTERNALHD. In this way, I in the Fstab file, you can use/DEV/INTERNALHD to replace the original/DEV/SDA. Next time, for some reason, the hard drive has become a SDB device name in the kernel, so don't worry, Udev will automatically generate/DEV/INTERNALHD this link and point to the correct/dev/sdb device. All other files such as fstab are not modified.

While the 2.6 kernel used to be DEVFS,DEVFS mounted in the/dev directory, provides a file-like way to manage all devices located in the/dev directory, but the Devfs file system has some drawbacks, such as: Indeterminate device mappings, Sometimes a device mapping device file may be different, for example my USB flash drive may correspond to the SDA may correspond to SDB.

Note: You can use the command to view the information in it, Udevinfo-a-P/SYS/BLOCK/SDA

Declaration, as a beginner, a lot of things do not understand, this article is not original, but I study when the reference to the Daniel article to collate, the following is part of the link of the article address, we can enter to see the original.

Some articles from the source:

Http://www.360doc.com/content/11/1218/16/1299815_173168170.shtml

http://www.ibm.com/developerworks/cn/linux/l-cn-udev/

20150225 IMX257 Device Driver Model Sysfs file system knowledge Point integration (II.)