什么是udev

linux传统上使用静态设备创建方法，因此大量设备节点在 /dev 下创建（有时上千个），而不管相应的硬件设备是否真正存在。通常这由一个MAKEDEV脚本，组成它由许多calls of mknod program with the revelant major and minor device number for每一个世界上可能存在的设备。采用udev的方法，只有被kernel检测到的设备才会get devices nodes created for them.因为这些设备节点在每次系统启动时被创建，他们会被stored在a ramfs(a file system in memory,does not take up any disk space).设备节点不需要much 磁盘空间，因此the memory that is used 可以忽略。

1:history
在2.4版本的kernel中，一种新文件系统called devfs被添加了进去。尽管它在kernel源码中出现，然而这种动态创建设备的方法从未收到压倒性的支持from core kernel开发者；
devfs的方法主要问题是 the way：设备检测,创建，命名。设备节点命名，可能是最critical的.It is generally accepted that 设备名允许是可配置的，then设备命名策略应该up to一个系统管理员,not 被欺骗by 特殊的开发者。devfs文件系统同时还忍受着一个紊乱情况，为它的design所固有，且不能被fix，若无实质的修改to kernel.现由于缺乏维护已被deprecated.
在2.6版本的kernel中，出现了一种叫sysfs的新虚拟文件系统。sysfs的任务是export系统架构 to 用户空间进程。有了这种用户空间visible表示法，the possiblity of seeing a userspace replacement for devfs 变得更加现实。

2：udev 执行
sysfs怎样知道设备出现在系统？应该使用什么设备号？对于被编进kernel的driver,当被kernel监测到时，直接注册目标with sysfs。使用模块方式编译的，当模块被load时，如前。once sysfs文件系统被mounted (on /sys),the data which the built-in drivers registered with sysfs are available to userspace process and to udev for device node creation.
udev初始化脚本创建这些设备节点当linux boot时；这个脚本starts with 注册/sbin/udev/ 作为一个 hotplug事件管理者。热插拔事件不应该发生在这个过程中，然而udev is registered just in case they do occur.然后udevstart program walk through the /sys filesystem and 创建符合描述的设备在/dev。例如：/sys/class/tty/vcs/dev/包括string "7:0".这个字符串被udevstart使用来创建/dev/vcs，主设备号7and此设备号0。每一个udevstart创建的设备的权限设置来自/etc/udev.d/permission.d/目录。这些numbered(有限的) 基本相似LFS bootscripts.如果找不到创建的设备权限文件，默认perissions to 600 and ownership to root:root./dev目录下创建的节点根据 /etc/udev/rules.d/目录下的文件来configured.
当一个新设备连接被kernel监测到，kernel会产生一个hotplug event 并查找/proc/sys/kernel/hotplug去找出管理设备连接的用户空间程序。udev初始化脚本注册udev as this hander.当hotplug events发生时，kernel通知udev 去检测/sys 文件系统附属于这个新设备的信息并create 它的/dev/入口。
？这带给我们一个问题：exists with udev,and likewise with devfs before it.？就像先有鸡还是先有蛋。大部分linux distrubtions
管理加载模块通过/etc/modules.conf.access to 设备节点引起相应的kernel模块来加载。然而对于udev,这种方法不能正常工作，因为模块没有加载时，设备节点不存在。为了解决这个问题，模块脚本加到了lfs-bootscripts包中，和/etc/sysconfig/modules在一起。通过添加module names到module file中，这些模块在计算机启动时被加载。这样，udev就可以去检测设备并创建相应的设备节点。

3：处理可热插拔/动态设备
当你插入一个设备，比如usb mp3 player,内核辨认出设备连接同时产生一个热插拔事件。如果驱动已经loaded(不管是编进kernel还是通过s05modules bootscript加载），udev将被调用来创建相关的设备节点，根据sysfs data in /sys.如果刚插入的设备驱动以模块形式然而并未加载，那么刚attach to system 的设备只会引起kernel总线驱动产生一个热插拔事件通知用户空间一个新设备的连接and它不attached to a driver.结果，什么都没有发生，device依然不能使用。
如果建立一个system,that具有大量的以模块形式编译的驱动，使用s05modules并不实际。the hotplug package()会显得非常有价值。当此包安装后，它会响应前述的kernel总线驱动hotplug事件。此包将加载相应的模块并为设备创建节点。

4：创建设备的问题
自动创建设备节点时常遇到的一些问题
1）A kernel driver may not exports its data to sysfs
当使用第三方驱动(在kernel source tree 之外）时常遇到这种问题。这些驱动end up时没有创建设备节点。使用/etc/sysconfig/creatfiles 配置文件to 人工创建设备。参考devices.txt文件（在kernel文档中）或者驱动文档来找出正确的major/minor设备号。
2）无硬件设备 is required.这种很常见with the advanced linux sound architecture(ALSA) project's open sound system(oss) compatibility 模块.这种形式的驱动可以使用以下下面两种方法来管理:
*将module names 加到 /etc/sysconfig/modules;
*使用"install"line 在/etc/modprobe.conf中。This tells the modprobe command "when loading this module, also load this other module,at the same time."例如
install snd-pcm modprobe -i snd-pcm;modprobe snd-pcm-oss;true
当系统中有加载snd-pcm驱动的请求时，这会使系统加载both snd-pcm and snd-pcm-oss modules.

5:进一步一些参考资料
http://fedora.redhat.com/docs/udev/
http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev.html
http://www.kroah.com/linux/talks/ols_2003_udev_paper/Reprint-Kroah-Hartman-OLS2003.pdf
http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev-FAQ

原文资料：

Linux systems in general traditionally use a static device creation method, whereby a great many device nodes are created under /dev (sometimes literally thousands of nodes), regardless of whether the corresponding hardware devices actually exist. This is typically done via a MAKEDEV script, which contains a number of calls to the mknod program with the relevant major and minor device numbers for every possible device that might exist in the world. Using the udev method, only those devices which are detected by the kernel get device nodes created for them. Because these device nodes will be created each time the system boots, they will be stored on a ramfs (a file system that resides entirely in memory and does not take up any disk space). Device nodes do not require much disk space, so the memory that is used in negligable.
7.4.1. History

In February 2000, a new filesystem called devfs was merged into the 2.3.46 kernel and was made available during the 2.4 series of stable kernels. Although it was present in the kernel source itself, this method of creating devices dynamically never received overwhelming support from the core kernel developers.

The main problem with the approach adopted by devfs was the way it handled device detection, creation, and naming. The latter issue, that of device node naming, was perhaps the most critical. It is generally accepted that if device names are allowed to be configurable, then the device naming policy should be up to a system administrator, not imposed on them by any particular developer(s). The devfs file system also suffers from race conditions that are inherent in its design and cannot be fixed without a substantial revision to the kernel. It has also been marked as deprecated due to a lack of recent maintenance.

With the development of the unstable 2.5 kernel tree, later released as the 2.6 series of stable kernels, a new virtual filesystem called sysfs came to be. The job of sysfs is to export a view of the system's structure to userspace processes. With this userspace visible representation, the possibility of seeing a userspace replacement for devfs became much more realistic.
7.4.2. Udev Implementation

The sysfs filesystem was mentioned briefly above. One may wonder how sysfs knows about the devices present on a system and what device numbers should be used. Drivers that have been compiled into the kernel directly register their objects with sysfs as they are detected by the kernel. For drivers compiled as modules, this will happen when the module is loaded. Once the sysfs filesystem is mounted (on /sys), the data which the built-in drivers registered with sysfs are available to userspace processes and to udev for device node creation.

The S10udev initscript takes care of creating these device nodes when Linux is booted. This script starts with registering /sbin/udev as a hotplug event handler. Hotplug events (discussed below) should not be generated during this stage, but udev is registered just in case they do occur. The udevstart program then walks through the /sys filesystem and creates devices under /dev that match the descriptions. For example, /sys/class/tty/vcs/dev contains the string “7:0” This string is used by udevstart to create /dev/vcs with major number 7 and minor 0. The permissions of each and every device that udevstart creates are set using files from the /etc/udev.d/permissions.d/ directory. These are numbered in a similar fashion to the LFS bootscripts. If udev cannot find a permissions file for the device it is creating, it will default permissions to 600 and ownership to root:root. The names of the nodes created under the /dev directory are configured according to the rules specified in the files within the /etc/udev/rules.d/ directory.

Once the above stage is complete, all devices that were already present and have compiled-in drivers will be available for use. What about those devices that have modular drivers?

Earlier, we mentioned the concept of a “hotplug event handler.” When a new device connection is detected by the kernel, the kernel will generate a hotplug event and look at the file /proc/sys/kernel/hotplug to find out the userspace program that handles the device's connection. The udev initscript registered udev as this handler. When these hotplug events are generated, the kernel will tell udev to check the /sys filesystem for the information pertaining to this new device and create the /dev entry for it.

This brings us to one problem that exists with udev, and likewise with devfs before it. It is commonly referred to as the “chicken and egg” problem. Most Linux distrubtions handle loading modules via entries in /etc/modules.conf. Access to a device node causes the appropriate kernel module to load. With udev, this method will not work because the device node does not exist until the module is loaded. To solve this, the S05modules bootscript was added to the lfs-bootscripts package, along with the /etc/sysconfig/modules file. By adding module names to the modules file, these modules will be loaded when the computer is starting up. This allows udev to detect the devices and create the appropriate device nodes.

Note that on slower machines or for drivers that create a lot of device nodes, the process of creating devices may take a few seconds to complete. This means that some device nodes may not be immediately accessible.
7.4.3. Handling Hotpluggable/Dynamic Devices

When you plug in a device, such a Universal Serial Bus (USB) MP3 player, the kernel recognizes that the device is now connected and generates a hotplug event. If the driver is already loaded (either because it was compiled into the kernel or because it was loaded via the S05modules bootscript), udev will be called upon to create the relevant device node(s) according to the sysfs data available in /sys. If the driver for the just plugged in device is available as a module but currently unloaded, then attaching the device to the system will only cause the kernel's bus driver to generate a hotplug event that notifies userspace of the new device connection and it not being attached to a driver. In effect, nothing happens and the device itself is not usable yet.

If building a system that has a lot of drivers compiled as modules rather than directly built into the kernel, using the S05modules may not be practical. The Hotplug package (see /) can be beneficial in these cases. When the Hotplug package is installed, it will respond to the aforementioned kernel's bus driver hotplug events. The Hotplug package will load the appropriate module and make this device available by creating the device node(s) for it.
7.4.4. Problems with Creating Devices

There are a few known problems when it comes to automatically creating devices nodes:

1) A kernel driver may not export its data to sysfs.

This is most common with third party drivers from outside the kernel tree. These drivers will not end up having their device nodes created. Use the /etc/sysconfig/createfiles configuration file to manually create the devices. Consult the devices.txt file inside the kernel documentation or the documentation for that driver to find the proper major/minor numbers.

2) A non-hardware device is required. This is most common with the Advanced Linux Sound Architecture (ALSA) project's Open Sound System (OSS) compatibility module. These types of devices can be handled in one of two ways:

*

Adding the module names to /etc/sysconfig/modules
*

Using an “install” line in /etc/modprobe.conf. This tells the modprobe command “when loading this module, also load this other module, at the same time.” For example:

install snd-pcm modprobe -i snd-pcm ; modprobe \
snd-pcm-oss ; true

This will cause the system to load both the snd-pcm and snd-pcm-oss modules when any request is made to load the driver snd-pcm.



发表于