Udev-minicom does not have the permission to open the serial port and change the permission of ttyUSB0

Udev-minicom does not have the permission to open the serial port and change the permission of ttyUSB0

Udev-minicom does not have the permission to open the serial port and change the permission of ttyUSB0

When you use minicom to open the serial port, you will be prompted that you do not have the permission. You must use sudo. How can you change the permission of the serial port device to allow normal users to read and write?

In fact, as long as you change the udev rules, the ttyUSB0 permission is 666, so that ordinary users can read and write.

Add udev rules:

/Etc/udev/rules. d/50-usb-serial.rules

KERNEL = "ttyUSB0", GROUP = "uucp", MODE = "0666"

Restart

Udev usage-create a device node in linux

In Linux, all exist in the form of device files. In earlier Linux versions, the/dev directory contains all possible device files. However, it is difficult for Linux users to find matching device files in these large numbers of device files. Now udev only generates device files for devices connected to the Linux operating system. In addition, udev can define a udev rule (rule) to generate device files that match device properties, these device attributes can be the kernel device name, bus path, vendor name, model, serial number, or disk size.

Dynamically and automatically manage device information: When a device is added/deleted, the udev daemon listens to uevent events from the kernel to add or delete Device Files under/dev, therefore, udev can only generate device files for connected devices, instead of generating a large number of Device Files under/dev like the 2.4 kernel. In addition, you can use this function to run external programs when a device is added, such as automatically disabling the touchpad when the mouse is added.
Use custom naming and device management: Using the Udev rule file, udev defines kernel device names for all devices in/dev/, such as/dev/sda,/dev/hda, And/dev/fd. Because udev runs in user space, Linux users can perform subsequent operations on this information. For example, they can generate a human device identifier through a custom rule file, for example,/dev/my_disk and/dev/nameusb can also modify the user group permissions of parameter members.

First, you need to know
? Sysfs: sysfs is a Virtual File System (/sys) in the Linux 2.6 kernel ). It exports device and driver information from the kernel device module to the user space (userspace ). In this file system, Linux users can obtain the attributes of many devices.
? Devpath: The devpath in this document refers to the relative path of a device under the sysfs File System (/sys), which contains the property file of the device. Most commands in udev operate on devpath. For example, the devpath of sda is/block/sda, And the devpath of sda2 is/block/sda/sda2.
? Kernel device name: the name of the device in sysfs. It is the default device file name used by udev.

Udev main configuration file

The main udev configuration file is/etc/udev. conf. This file is usually very short. It may only contain comments starting with "#" and there are several options:

Udev_root =/dev/# sets the absolute path, which is equivalent to creating the root of the chroot. Udev_rules =/etc/udev/rules. d/# rule storage address Udev_log = err # log input level

Udev rule configuration file instance

The default rule configuration file is stored in/etc/udev/rules. d/. We can see that RedHat creates some rules for devices by default and some rules written by hardware companies.
Go to the directory. You can see the configuration file prefixed with two digits. You can use vi to enter the configuration file and view it. One row is a rule. The default value is from small to large, these indicate the order in which the values take effect.

Before using udev to write rules, let's look at an example.

KERNEL = sd *, PROGRAM =/lib/udev/scsi_id-g-s % p, RESULT = 123456, SYMLINK = % k _ % c

Execution of this rule: if a kernel device name starts with sd and the scsi id is 123456, a symbolic link "sda_123456" is generated for the device file ". % p % k % c please refer to"Udev value and callable replacement Operator"

Udev Rule Configuration File

In the rule file, except for the rows (comments) starting with "#", all non-empty rows are regarded as one rule, but one rule cannot be extended to multiple rows. The rules are composed of multiple key-value pairs (pairs) separated by commas (,). key-value pairs can be divided into condition matching key-value pairs (hereinafter referred to as "Matching key ") A rule can have multiple matching keys and multiple value assignment keys. A matching key is a condition that matches all the properties of a device. When a property of a device matches all the matching keys in the rule, the rule takes effect and then follows the value assignment key, assign a value to execute this rule.
The rules in the Rule file consist of a series of key/value pairs, which are separated by commas.

These configurations can also be seen in the above example, but I think you may wonder why the KERNEL is the matching key and the NAME and MODE are the value assignment keys? This is determined by the operator in the middle.

Only when the operator is "=" or "! = ", It is the matching key; if it is another operator, it is the value assignment key.

The following table describes the matching key and value assignment key operators:

Operator matching or value assignment t Interpretation ---------------------------------------- = Matching equal comparison ! = Unequal matching comparison = Assign a specific value to the key, which can overwrite the previous value. + = Assign a value to append a specific value to an existing key. : = Assign a specific value to the key, and the subsequent rules cannot overwrite it.

Udev rule matching key:

Key description ---------------------------------------- ACTION event, such as add (add device) and remove (delete device ). The name of the device that the KERNEL sees in the KERNEL. For example, sd * indicates any SCSI disk device. Enter the DEVPATH kernel device, such as/devices /* SUBSYSTEM name. For example, the sda SUBSYSTEM is block. BUS name, such as IDE, USB DRIVER device DRIVER name, such as ide-cdrom The device ID is independent of the kernel name. SYSFS {value} sysfs attribute value, which can represent any ENV {key} environment variable, which can represent any An executable PROGRAM of the PROGRAM. If the PROGRAM returns 0, the key is considered true) The standard output returned by the previous PROGRAM call of RESULT. NAME of the device file created according to this rule. Note: Only the NAME description in the first line is valid and is ignored later. If you want to use more than two names to access a device, consider the SYMLINK key. SYMLINK is a symbolic link generated for device files under/dev. Because udev can only generate one device file for a device, We recommend that you use Symbolic Links to avoid overwriting the files generated by the system's default udev rules. OWNER device file OWNER The GROUP where the GROUP device file is located. The permission of the MODE Device File in octal format. List of programs RUN for the device LABEL used for internal control in the configuration file (the following GOTO Service) GOTO jumps to matching rules (identified by LABEL ). IMPORT {type} IMPORT the Rule Set generated after a file or program is executed to the current file WAIT_FOR_SYSFS waits for the creation of a specific device file. It is mainly used for timing and dependency issues. PTIONS specific options: Last_rule executes the terminal rules of such devices; Ignore_device ignores the current rule; Ignore_remove ignores the next request and removes it. All_partitions creates device files for all disk partitions.

We provide a column to explain how to use these keys. The following example is from the standard configuration file of the Fedora Core 5 system.

KERNEL = "*", OWNER = "root" GROUP = "root", MODE = "0600 ″
KERNEL = "tty", NAME = "% k", GROUP = "tty", MODE = "0666", OPTIONS = "last_rule"
KERNEL = "scd [0-9] *", SYMLINK + = "cdrom-% k"
KERNEL = "hd [a-z]", BUS = "ide", SYSFS {removable} = "1 ″, SYSFS {device/media }== "cdrom", SYMLINK + = "cdrom-% k"
ACTION = "add", SUBSYSTEM = "scsi_device", RUN + = "/sbin/modprobe sg"

The preceding example provides five rules, each starting with the KERNEL or ACTION key:

* The first rule is the default rule. It matches any device identified by the kernel and sets the owner group of these devices as root and the group as root, access permission mode is 0600 (-rw ---). This is also a safe default setting to ensure that only the root user can read and write all devices by default.
* The second rule is also a typical rule. It matches the terminal device (tty) and then sets the new permission to 0600. The group is tty. It also sets a special device file name: % K. In this example, % k indicates the kernel name of the device. This means that the kernel identifies the names of these devices and creates the file names.

* The KERNEL = "scd [0-9] *" starting from line 3 indicates the SCSI CD-ROM driver. It creates a pair of device symbolic connections: cdrom and cdrom-% k.

* In the fourth line, the starting KERNEL = "hd [a-z]" indicates the ata cdrom Drive. This rule creates a symbolic connection with the above rule. The ata cdrom driver requires sysfs value to distinguish other ATA devices, because scsi cdrom can be uniquely identified by the kernel ..

* The fifth line starts with ACTION = "add". It 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 result is that the computer should add the sg kernel module to detect new SCSI devices.

Of course, the above is just a small example. If your system adopts the udev method, you should be able to see more rules. If you want to modify the device permission or create a symbolic connection, you need to read these rules carefully, especially those devices related to the change.

Udev value and callable replacement Operator

The key-value pairs and operators are all described, and finally the value ). Linux users can customize the value of the udev rule file at will. For example, my_root_disk and my_printer. You can also reference the following replacement operators: ---------------------------------------- $ Kernel, % k: the device's kernel device name, such as sda and cdrom. $ Number, % n: the kernel number of the device. For example, the kernel number of sda3 is 3. $ Devpath, % p: devpath of the device. $ Id, % B: id of the device in devpath. $ Sysfs {file}, % s {file}: file Content in the sysfs of the device. It is actually the property value of the device. For example, $ sysfs {size} indicates the size of the device (Disk. $ Env {key}, % E {key}: the value of an environment variable. $ Major, % M: The major number of the device. $ Minor % m: the minor number of the device. $ Result, % c: result returned by PROGRAM $ Parent, % P: name of the parent device. $ Root, % r: udev_root value. The default value is/dev /. $ Tempnode, % N: temporary device name. %: Symbol % itself. $: Symbol $ itself.

 

Query of information required by udev rules

Common commands for checking the above key information

Udevinfo-a-p $ (udevinfo-q path-n/dev/sda1) The preceding command uses udevinfo twice: The first time is to return the sysfs device path (which is usually different from the path of the Linux Device File name --/dev/hda -- we see ); The second query is the device path, and the result is a summary of non-common syfs information. Udevinfo-a-p/sys/class/net/eth0 Scsi_id-g-s/block/sda Scsi_id-g-x-s/block/sda/sda3 Ata_id/dev/hda

Test and take effect of udev Information

How can I test the rule based on the content in the above file?

Udevtest/block/sda

Start_dev # restart the udev daemon

This operation re-queries all rule files in the Rule directory for all devices and then executes the actions in the matched rule.

This command is usually used to make the new rule file take effect immediately.