Author: Liu Xuhui colorant@163.com reproduced please indicate the source of http://blog.csdn.net/colorant/
There are many articles related to udev. The main purpose of this article is not to provide a complete teaching document, but to provide the main resources available on the Internet. Focus on analyzing its basic working principles and some problems that have not been explicitly stated in the README documentation during use.
1. Basic ConceptsThe udev file system is designed for the 2.6 kernel and provides a solution for managing and naming dynamic device nodes based on user space, there are a lot of articles on the comparison between udev file system and devfs file system. If you want to know about this, please search for related keywords directly. Udev Official Website: http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev.htmlsrc code: http://www.us.kernel.org/pub/linux/utils/kernel/hotplug/ In addition, about udev's rules rule writing, there are a lot of articles online, if you want to get the most accurate version, you can find the writing_udev_rules help document in the SRC code tree. This document does not actually introduce all the keywords of rules one by one, you can combine man udev and udev's built-in rules files to understand how to write the rule files you need.
2 install and start
2.1 installationUdev has many versions in the code tree, and the latest version I downloaded is the udev-117, which works properly with the 2.6.21 kernel. Many articles on the Internet may be about earlier versions. Some steps, including the udev readme document, seem to be not very accurate. Basically, in this version of udev, you must note that only udevd and udevadm files are required for installation. Other required files, including udevtrigger, are only a symbolic link of udevadm. Udevstart is not required. Of course, the configuration files such as udev. conf are the same.
2.2 startYou can use the udevd-D parameter in the startup script to start the udev File System daemon, and then use udevtrigger to create the node driven by the buildin device, after the module is inserted and removed, it will be automatically managed. The prerequisite for loading udev normally includes the following operations: configure the PATH variable and load the sysfs file system. Load a ram-based writable/dev directory (in fact, you only need to provide a writable directory, and the directory path itself can be configured.) The created console node and null node scripts must be in the/dev directory: # Set the pathpath =/bin:/sbin:/usr/bin: /usr/sbinexport path # Mount proc and devpts filesystem/bin/Mount-amknod/dev/console C 5 1 mknod/dev/null C 1 3/sbin/udevd-D/sbin the fstab file used by/udevtrigger mount is similar to the following: none/tmp ramfs defaults 0 0 udev/dev ramfs defaults 0 0no Ne/proc defaults 0 0 sysfs/sys sysfs defaults 0 0 Of course, you may need to create some other device nodes in advance on your system, for example, the serial port ttysx can start the shell normally, and the above script is executed, it depends on the specific situation.
3. Thinking about Some Problems in use
3.1 Multiple matching of rulesThe help document states that a device can be matched multiple times by multiple rules. However, it must be clear that only multiple symlinks can be added for multiple matches and multiple names cannot be created. For example: kernel = "mtdblock4", name + = "mtdbb4" kernel = "mtdblock4 ", name + = "% K" only creates/dev/mtdbb4 instead of/dev/mtdblock4, similar to: Kernel = "mtdblock4 ", name + = "mtdbb4" kernel = "mtdblock4", symlink + = "mtdbb4link" can work normally.
3.2 udev. conf syntaxYou may find that there seems to be no detailed description of udev. the conf statement can be seen from the udevd code: udev. in the conf file, only these three parameters will be parsed: udev_root defines the udev directory path udev_rules defines the udev rule file directory path udev_log defines the log level. Maybe some other configuration parameters will be added later?
4. Basic working principlesThis section mainly analyzes the udev source code and its understanding of some of your concerns.
4.1 how does udevd obtain the dynamic information of these kernel modules?The device node is created by analyzing the dev file through the sysfs interface to obtain the device node number, which is obvious. So what mechanism does udevd learn about the changes of modules in the kernel and how does it know the insertion and removal of devices? Of course, it's through the hotplug mechanism. How is hotplug implemented? Or how does the kernel notify users of an event? The answer is to transmit information between the kernel and the user space through netlink socket communication. The kernel calls the kobject_uevent function to send the Netlink message to the user space, which usually does not need to be processed by the driver. In the unified device model, at the subsystem layer, this part of the code has been processed, including sending the add and remove messages when the specified kobject of the device is created and removed, of course, the premise is that you have configured Hotplug support in the kernel. Netlink socket, as a communication method between the kernel and the user space, is not only used in the hotplug mechanism, but also applied to many other kernel subsystems related to the real and network. Udevd uses the standard socket mechanism to create a socket connection to obtain uevent events broadcast by the kernel and parse these uevent events.
4.2 How udevd monitors changes to rule filesIf the kernel version is new enough, udev can automatically re-apply these rules when the rule file changes, thanks to the kernel inotify mechanism, inotify is a file system change notification mechanism. Events such as file addition and deletion can be immediately known to users. In udevd, The Netlink socket file descriptors of inotify and udev are all selected. Further processing is performed after an event occurs.
4.3 how does udevtrigger work?After running udevd, when udevtrigger is used, the existing device nodes in the kernel will be created. How does this happen? By analyzing the udevtrigger code, we can see that udevtrigger triggers uevent events by writing the "add" string to the uevent node of an existing device in the/sysfs file system so that udevd can receive these events, create the device nodes of the device driver of buildin and all the device nodes of the insmod module. Therefore, we can also manually use the command line to simulate this process: /# echo "add">/sys/block/mtdblock2/uevent/# uevent [178.415520] Add/block/mtdblock2 (Block), but read the code further, you will find that, no matter what you write to uevent, The add event will be triggered. The default implementation is as follows: static ssize_t store_uevent (struct device * Dev, struct device_attribute * ATTR, const char * Buf, size_t count) {kobject_uevent (& Dev-> kobj, kobj_add); Return count ;} so no matter what the content is written, the add operation is triggered. Sorry, I still want to pass This operation is used to remove the property experiment. I don't know why. The implementation of udevstart is different from that of udevtrigger. It basically implements the mechanism in udevd repeatedly. By traversing sysfs, you can create your own device nodes instead of udevd.
4.4 othersØ when udevd creates a node, it will fork a new process to create the node separately. Ø uevent_seqnum is used to identify the serial number of the current uevent event (How many uevent events have been generated). You can perform the following operations: $ CAT/sys/kernel/uevent_seqnum2673
