Shulou(Shulou.com)06/02 Report--

Udev profile

The main udev configuration file is / etc/udev/udev.conf. This file is usually very short, it may just contain a few lines of comments starting with #, and then have a few lines to choose from.

Item:

Udev_rules= "/ etc/udev/rules.d/"

Udev_log= "err"

The second line above is important because it represents the directory stored by the udev rule, which stores files that end with .rules. Each file is processed one

A series of rules to help udev assign names to device files to ensure that they are recognized by the kernel.

There may be several udev rule files under your / etc/udev/rules.d, some of which are installed by the udev package, while others may be

Generated by other hardware or software packages. For example, on Fedora Core 5 systems, the sane-backends package installs the 60-libsane.rules file, and

The external initscripts package installs the 60-net.rules file. The file names of these rule files usually start with two numbers, which indicates the order in which the rule is applied by the system.

The rules in the rules file consist of a series of key / value pairs separated by a comma (,). Each key is either a user match key or an assignment key.

The match key determines whether the rule is applied, and the assignment key indicates that a value is assigned to the key. These values affect the device files created by udev. The assignment key can handle a

Multi-value list. The match key and assignment key operators are explained in the following table:

Udev key / value pair operator

Operator matching or assignment t interpretation

--

= = match equality comparison

! = match unequal comparison

Assignment assigns a specific value to the key, which can override the previous assignment.

+ = assign append a specific value to an existing key

: = assign a specific value to the key, and it is impossible for subsequent rules to override it.

This is a bit similar to our common programming languages, such as C language. It's just that the keys here can handle multiple values at a time. Some keys are often listed in the udev rules file.

Now, the values of these keys can use wildcards (*,?, or even ranges, such as [0-9]). These common keys are listed as follows:

Commonly used udevkey

Key meaning

ACTION the name of an event activity, such as add, when the device is added.

The device name that KERNEL sees in the kernel, such as sd* for any SCSI disk device

DEVPATH kernel device path, such as / devices/*

SUBSYSTEM subsystem name, such as sound,net

The name of the BUS bus, such as IDE,USB

The name of the DRIVER device driver, such as ide-cdrom

ID device name independent of kernel name

The value of the SYSFS {value} sysfs property, which can represent any

ENV {key} environment variable, which can represent any

PROGRAM executable external program, if the program returns a value of 0, the key is considered true (true)

The standard output returned by the last PROGRAM call to RESULT.

The file name of the device file created by NAME according to this rule. Note: only the NAME description on the first line is valid, and the rest is ignored. Such as

If you want to use more than two names to access a device, consider the SYMLINK key.

The character connection name created by SYMLINK according to the rule

Subordinate groups of OWNER device files

The group in which the GROUP device file belongs.

Permissions for MODE device files, using octal

List of programs executed by RUN for the device

The name tag used by LABEL for internal control in the configuration file (the following GOTO service)

GOTO jumps to matching rules (identified by LABEL), which is somewhat similar to GOTO in a programming language

IMPORT {type} imports a file or a rule set generated by the execution of a program into the current file

WAIT_FOR_SYSFS waits for the creation of a specific device file. It is mainly used for timing and dependency problems.

PTIONS specific options: last_rule executes terminal rules for such devices; ignore_device ignores current rules

Ignore_remove ignores the next request and removes the request.

All_partitions creates device files for all disk partitions.

We give a column to explain how to use these keys. The following example comes from the standard configuration file for the Fedora Core 5 system.

The above example shows five rules, each beginning with the KERNEL or action key:

* the first rule is default. It matches any device recognized by the kernel, and then sets the subordinate group of these devices to root, the group to root, and the access mode to

0600 (- rw---). This is also a secure default setting that ensures that only root can read and write to all devices by default.

* the second rule is also a more typical rule. It matches the end device (tty) and then sets the new permission to 0600, which is in the group tty. It also sets a

Special device file name:% K. In this example,% k represents the kernel name of the device. That means that the kernel recognizes the names of these devices,

What kind of device file name to create.

* KERNEL== "scd [0-9] *" at the beginning of the third line, indicating the SCSI CD-ROM driver. It creates a pair of device symbolic connections: cdrom and cdrom-

% k.

* the fourth line, the beginning of KERNEL== "hd [a Murz]", indicates the ATA CDROM drive. This rule creates the same symbolic link as the rule above. ATA

The CDROM driver needs the sysfs value to distinguish other ATA devices because SCSI CDROM can be uniquely recognized by the kernel. .

* the fifth line begins with ACTION== "add", which tells udev to add / sbin/modprobe sg to the command list when any SCSI device is added to the system

These commands will be executed. The effect is that the computer should add sg kernel modules to detect new SCSI devices.

Of course, the above are just a few examples, and if your system uses udev, you should be able to see more rules. If you want to modify the equipment

Permissions or create symbolic links to letters, then you need to familiarize yourself with these rules, especially to pay close attention to the devices you modify.

Modify your udev configuration

Before modifying the udev configuration, we must be careful. The usual consideration is: you'd better not modify the rules that are preset by the system, especially do not specify that the impact is very

Extensive configuration, such as the first line in the example above. Incorrect configuration may lead to serious system problems or the system simply cannot have this correct access setting.

Ready.

The right thing to do is to create a rule file for the letter under / etc/udev/rules.d/. Make sure that the suffix of the file you give is the rules file name

The sequence of numbers should be higher than the standard profile. For example, you can create a rule file called 99-my-udev.rules. In your rules file, you

You can specify any configuration you want to modify, for example, suppose you modify the group that modifies the floppy device, and you are ready to create a symbolic link of the letter.

Then / dev/floppy, then you can write:

Some distributions, such as Fedora, use external scripts to modify the group, group relationships, and permissions of certain devices. Therefore, the above changes may not be seen.

It has to work. If you encounter this problem, you need to track and modify the script to achieve your goal. Or you can modify the PROGRAM or Run key

To do this.

Changes to some rules may require deeper mining. For example, you might want to use sysfs information on a device to uniquely identify a device. This information is the best.

Get it through the udevinfo command.

The above command uses udevinfo twice: once to return the path to the sysfs device (which is usually the same path as the Linux device file name we see-

-/ dev/hda-- is different); the second time is to query the device path, and the result will be a summary of unusual syfs information. You can find the most information to be unique.

To mark your device, you can replace the SYSFS option in the udev configuration file as appropriate. The following result is the command output above

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 be composed by the attributes of the device

And the attributes from one 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} = "63"

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 0218340 1283968"

ATTRS {size} = "117210240"

ATTRS {removable} = = "0"

ATTRS {range} = "64"

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} = = "11"

ATTRS {class} = = "0x01018a"

ATTRS {subsystem_device} = = "0xc009"

ATTRS {subsystem_vendor} = = "0x144d"

ATTRS {device} = = "0x24ca"

ATTRS {vendor} = "0 × 8086"

Looking at parent device'/ devices/pci0000:00':

KERNELS== "pci0000:00"

SUBSYSTEMS== ""

DRIVERS== ""

Take an example: suppose you want to modify the configuration of the USB scanner. Through a series of attempts, you have identified the Linux device file for this scanner (each time you type

The name changes when you turn on the scanner. You can replace the correct Linux device file name with the command above, and then locate the use of the output

SYSFS {idVendor} lines and SYSFS {idProduct} lines. Finally, you can use this information to create new options for this scanner.

SYSFS {idProduct} = "400e",\

SYMLINK+= "scanner", MODE= "0664",\

Group= "scanner"

The above example shows that the group of the scanner is set to scanner, the access permission is set to 0664, and a symbolic link of / dev/scanner is created.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.