Linux┊ detailed Udev

is a small example, if your system takes the form of udev, you should see more rules. If you want to modify the permissions of a device or create a symbolic connection to a letter, you need to familiarize yourself with these rules, especially with regard to the devices that you modify.

Modify your Udev configuration

Before modifying the Udev configuration, we have to be careful, the usual consideration is: you'd better not modify the rules of the system presets, especially not to specify a very extensive configuration, such as the first line in the example above. Improper configuration can cause serious system problems or the system will not be able to access the device at all.

And the right thing to do is to create a rule file for a letter under/etc/udev/rules.d/. Make sure you give the file a suffix that the rules file name gives a sequence of numbers that should be higher than the standard configuration file. For example, you can create a rule file named 99-my-udev.rules. In your rules file, you can specify any configuration you want to modify, for example, if you modify the group that modifies the floppy device, and you are ready to create a symbolic connection/dev/floppy of the letter, then you can write:

kernel== "fd[0-9]*", group= "users", symlink+= "floppy"

Some distributions, such as Fedora, use an external script to modify the group, group relationships, and permissions for certain devices. Therefore, the above changes may not be effective. If you encounter this problem, you need to track and modify the script to achieve your goal. Or you can change the value of the program or run key to do this.

Modifications to some rules may require deeper digging. For example, you might want to use SYSFS information on a device to uniquely identify a device. This information is best obtained through the Udevinfo command.

$ udevinfo–a–p $ (udevinfo–q path–n/dev/hda) above command two times use Udevinfo: Once is to return the SYSFS device path (he usually and we see the path of the Linux device file name--/dev/hda--not The second time is the query for this device path, and the result will be a SYFS summary of non-regular information. You can find the best information to uniquely flag your device and you can use the SYSFS option in the appropriate replacement udev configuration file. The following result is the command output above

[[email protected] rules.d]# Udevinfo-a-P $ (udevinfo-q path-n/dev/hda1)
Udevinfo starts with the device specified by the Devpath and then walks up the chain of
Parent devices. It prints for every device found,all possible attributes in the Udev rules
Key format. A rule to match, can is composed by the attributes of the device and the
Attributes from a single parent device.

Looking at device '/block/hda/hda1 ':      
kernel== "hda1"      subsystem== "Block"      driver== ""         
attr{ stat}== "        1133         2268             2             4 "         attr{size}==" 208782 "
attr{start}= = "attr{dev}=="          "3:1"          Looking at parent device '/block/hda ':   

kernels== "Hda" subsystems== "block" drivers== ""
attrs{stat}== "28905 18814 1234781 302540 34087 133247 849708 981336 0 218340 1283968"
attrs{size}== "117210240" attrs{removable}== "0"
attrs{range}== "" attrs{dev}== "3:0"

Looking at parent device '/devices/pci0000:00/0000:00:1f.1/ide0/0.0 ':

kernels== "0.0" subsystems== "IDE" drivers== "Ide-disk"
attrs{modalias}== "Ide:m-disk" attrs{drivename}== "HDA"
attrs{media}== "Disk"
Looking at parent device '/DEVICES/PCI0000:00/0000:00:1F.1/IDE0 ':

kernels== "Ide0" subsystems== "" drivers== ""
Looking at parent device '/DEVICES/PCI0000:00/0000:00:1F.1 ':
kernels== "0000:00:1F.1" subsystems== "PCI" drivers== "Piix_ide"
attrs{broken_parity_status}== "0" attrs{enable}== "1"
attrs{modalias}== "pci:v00008086d000024casv0000144dsd0000c009bc01sc01i8a"
attrs{local_cpus}== "1" attrs{irq}== "one" attrs{class}== "0x01018a"
attrs{subsystem_device}== "0xc009" attrs{subsystem_vendor}== "0x144d"
attrs{device}== "0x24ca" attrs{vendor}== "0x8086"
Looking at parent device '/devices/pci0000:00 ':

kernels== "pci0000:00" subsystems== "" drivers== ""
Give an example: suppose you want to modify the configuration of a USB scanner. With a series of attempts, you've identified a Linux device file for this scanner (the name changes every time you open the scanner). You can replace the correct Linux device file name with the above command, and then locate the output with Sysfs{idvendor} lines and sysfs{idproduct} rows. Finally, you can use this information to create new options for this scanner.

sysfs{idvendor}== "0686", sysfs{idproduct}== "400e",
symlink+= "Scanner", mode= "0664", group= "scanner" above example means set the scanner's group to scanner, access permission set to 0664, and create a/dev/scanner symbolic connection.

Udev-faq

Q: What is Udev? What is the purpose of it?

A: Udev is a tool that dynamically updates the device files according to the state of the hardware devices in the system, including the creation, deletion, etc. of the device files. The device files are usually placed in the/dev directory. With Udev, only the devices that really exist in the system are included in the/dev directory.

Q: What kernel does udev support?

A: Udev only supports the linux-2.6 kernel, because Udev relies heavily on the information provided by the Sysfs file system, whereas the Sysfs file system is only available in the linux-2.6 kernel.

Q: Is udev a kernel program or a user program?

A: Udev is a user program (User-mode daemon).

Q: What is the difference between Udev and DEVFS?

A: Udev is able to implement all the functions that DEVFS implements. But Udev runs in user mode, while DEVFS is running in kernel mode. It is said that Devfs has some congenital defects that are not easily resolved.

Q: Where is the udev configuration file placed?

A: Udev is a user-mode program. Its configuration file is/etc/udev/udev.conf. This file typically has these items by default:

udev_root= "/dev"; The root directory of the device files produced by Udev is/dev
udev_db= "/dev/.udevdb"; A database formed from a device file produced by Udev
Udev_rules= "/ETC/UDEV/RULES.D"; the directory where the rules used to guide udev work.
Udev_log= "Err", when an error occurs, the error message is logged with the syslog.

Q: What is the working process of udev?

A: Since we have not studied the source program of Udev, I dare not say the work process of udev. I'm just using some of the information on the web and the Udev documentation to roughly guess how it might work.

When the kernel detects that a new device appears on the system, the kernel generates a new record for the new device in the Sysfs file system, and the general Sysfs file system is mount to the/sys directory. The new record is represented as one or more files or directories. Each file contains specific information. (How does the information be expressed and what else should be studied?) )

Udev is UDEVD in the system as a daemon, and it passes some way (in the end, it is not understood at all.) ) detects the presence of a new device and obtains some information about the device by locating records in the corresponding SYSFS of the device.

Udev examines the files in this directory, based on the directory specified in the/etc/udev/udev.conf file Udev_rules, and the files in this directory are rules files that should be implemented for a particular class or device. Udev reads files according to the ASCII alphabetical order of the filenames, and if Udev finds a rule that matches the newly added device, Udev configures the new device according to the actions defined by the rule. The subsequent rule files are not read at the same time.

Q: What is the syntax of Udev's rules file?

A: Udev's rules file is in the behavior unit, and the line that begins with "#" represents the comment line. Each of the remaining lines represents a rule. Each rule is divided into one or more "match" and "assignment" sections. The match section is represented by a keyword that is specific to match, and the corresponding assignment section is represented by the keyword assigned to it. The "Match" keyword includes: ACTION,KERNEL,BUS,SYSFS, etc., the "assignment" keyword includes: Name,symlink,owner and so on. Detailed descriptions can read the Udev man documentation.

Here is an example of a rule: subsystem== "net", action== "Add", sysfs{address}== "00:0d:87:f6:59:f3″, import="/sbin/rename_ Netiface%k Eth0″
The "Match" section in this rule has three items, namely Subsystem,action and SYSFS. In the "Assignment" section there is an import. This rule means that when the new hardware appearing in the system belongs to the net subsystem category, the system takes the action to join this hardware, and this hardware in the Sysfs file system "address" information equals "00:0d ...", The action of this hardware at the udev level is to invoke the external program/sbin/rename_netiface, passing parameters of two, one is "%k", which represents the name of the kernel for the new device definition.    The other is "eth0". As can be seen from the above example, Udev's rules are more flexible, especially in the "Match" section, where you can flexibly match multiple matches by using shell wildcard characters such as "*", "?", [a-c],[1-9], and so on. The specific syntax can refer to the Udev man document.

Q: How does Udev maintain a unified device name regardless of the order in which the devices are connected?

A: In fact, Udev achieves this 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.

Q: How can I find these device information and put them in the Udev rules file to match it?

A: This problem is difficult, the online information is not much, I only found an article to describe how to write udev rules. His basic approach is to use the Udevinfo utility to find items that can be used as matches in a rule file. There are two scenarios in which this tool can be used:

In the first case, when you plug the device into the system, the system generates a device name (such as/DEV/SDA) for the device. That kind of
Words, you first use udevinfo-q PATH-N/DEV/SDA, command will produce a device name corresponding to the path under SYSFS, such as/BLOCK/SDA. Then, with Udevinfo-a-p/sys/block/sda, this command displays a bunch of messages, divided into chunks. This information is actually derived from the SYSFS linked list maintained by the operating system, and different blocks correspond to different paths. You can use this information as a match in the Udev rules file. However, it is important to note that the same rule can only use the information displayed in the same block and cannot write rules across blocks.

The second situation is, do not know the system produces the device name, then only to the/sys directory down directory search, repeatedly used Udevinfo-a-p/sys/path ... This command looks at the information, if the corresponding information is the device, then congratulations. Otherwise, change the directory. Of course, in this case, the likelihood of success is relatively small.

Q: What is the relationship between Udev and Devfs?
A: Udev works entirely in the user state (userspace), using the HotPlug events (event) sent by the kernel when the device is joined or removed. Detailed information about the device is from the kernel output (export) to the Sysfs file system located in/sys. All device naming policies, permissions control, and event handling are done in a user-state. In contrast, DEVFS is working as part of the kernel.

Q: If Udev is unable to complete all DEVFS work, why is DEVFS marked as obsolete/removed?

Answer: Refer to Al Viro (Linux VFS kernel maintainer):

The work done by-DEVFS is assured that it can be done in user mode.
When-devfs was added to the kernel, it was hoped that its quality would catch up.
-devfs was found to be repairable and irreparable bugs.
-Fixed bugs that have been fixed a few months ago and maintained by defenders that everything is fine.
-For the latter, the same has been quite common for some time.
The maintainer and author of the-DEVFS is disappointed in it and has stopped the maintenance of the code.

Q: But when a/dev node does not exist, Udev does not automatically load the driver as DEVFS.
A: That's true, but Linux is designed to load modules when the device is discovered, rather than when it is accessed.

Q: But wait, I do hope that udev can automatically load the driver when a nonexistent node is opened. That's the only reason I'm using DEVFS. Add this function to Udev.
A: No, udev is used to manage/dev, not to load kernel drivers.

Q: Hi, please. It's not hard to do.
A: 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 the device drivers to stay in memory, you should use something else to manage your modules (such as scripts, modules.conf, etc.) that's not the work of Udev.

Q: But I really like that feature, or add it.
A: 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.

Q: I like the DEVFS device file naming method, can udev name it?
A: Yes, Udev can use the/dev naming policy to create nodes. With a configuration file, you can map the kernel default name to the DEVFS name. You can look at the Udev.rules.devfs files in Udev. Note: The naming of DEVFS is not recommended and is not officially supported, because it is a simple way to enumerate devices in situations where the device may be added or deleted at any time. These numbers will give you only trouble and cannot be used to determine the device. Look at the rules of the permanent disk (Persistentdisk) and know how to do it correctly in the user state, rather than simply list the device.

Q: What devices can udev create nodes for?
A: All devices displayed in Sysfs can be created by Udev to create nodes. If the kernel adds support for other devices, Udev will automatically be able to work for them. Now all the block devices are supported, and most of the main character devices are supported. Kernel developers are working to get all the character devices to be supported. You can find patches on the Linux-kernel mailing list or check the status of patches.

Q: Does udev remove the limit on the number of anonymous devices?
A: Udev works completely in user mode. If the kernel supports more anonymous devices, Udev will support it.

Q: Does Udev support symbolic links?
A: Udev now supports symbolic links, and it is supported for each device node to have multiple symbolic links.

Q: How does udev handle the/dev file system?
A: It is recommended to use a TMPFS that is recreated every time the system is started as the file system of/dev. In practice, however, Udev does not care about the file system being used.

Q: How does udev handle the device before Init runs?
A: 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.

Q: Can I use Udev to automatically load this device when a USB device is loaded?
A: Technically it is possible, but Udev is not used for this job. All major releases (distro) contain HAL (Http://freedesktop.org/wiki/Software_2fhal) for this work, which is also designed to monitor device changes, and integrates into the desktop software.

In other words, this can be achieved simply by Fstab:/dev/disk/by-label/pendrive/media/pendrive vfat user,noauto 0 0
This allows the user to access the device using the following command:
$mount/media/pendrive
It also does not require administrator privileges, but it has full access to the device. Using a Persistent disk link (label, UUID) will allow you to specify the same device, regardless of its actual kernel name.

Q: Are there any security issues that I need to be aware of?
A: When using the dynamic device number, a given master/slave device number may correspond to different devices at different times, if a user has access to the node, and can create a hard link to this node, he can get a copy of this device node. When the device is removed, Udev removes the device node, but the hard link still exists. If the device node is later reused with different access rights, its hard links can still be accessed using the previous access permissions. (The same problem also exists on login that uses PAM to change access rights.) )

A simple solution is to prevent the creation of hard links by placing/dev on a separate file system such as TMPFS.

Linux┊ detailed Udev