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

This article mainly introduces how to write the basic udev rules in Linux, which has a certain reference value, interested friends can refer to, I hope you can learn a lot after reading this article, let the editor take you to understand it.

Reader object

Understand the basic concepts behind udev and learn how to write simple rules.

Request

Root permission

Difficulty

Medium

Agreement

#-A given command is required to be run either directly as a root user or using the sudo command with root permissions.

$- requires the given command to be run as an ordinary unprivileged user.

Introduction

In GNU/Linux systems, although the underlying support of devices is handled at the kernel level, their related event management is managed through udev in user space. To be exact, it is done by the udevd daemon. Learning how to write rules and apply them to these events will help us modify the behavior of the system and adapt it to our needs.

How the rules are organized

Udev rules are defined in a file with a .rules extension. Those files are mainly placed in two locations: / usr/lib/udev/rules.d, which is used to hold the rules for system installation, and / etc/udev/rules.d/, which is reserved for custom rules.

The naming convention for files that define those rules uses a number as a prefix (for example, 50-udev-default.rules) and is processed in the order in which they are lexical in the directory. Files installed in / etc/udev/rules.d will overwrite files with the same name installed in the default path of the system.

Rule grammar

If you understand the behavioral logic of udev rules, its syntax is not complicated. A rule consists of two main sections: the match section, which uses a series of comma-separated keys to define the conditions under which the rule is applied, and the action part, where we perform some actions when the conditions are met.

Test case

The only way to explain the possible options is to configure a real case, so let's define a rule as a demonstration to disable the touchpad when the mouse is connected. Obviously, the attributes provided in the rule definition will reflect my hardware.

We will write our rules in the / etc/udev/rules.d/99-togglemouse.rules file with our favorite text editor. A rule definition allows you to span multiple lines, but if this is the case, you must use a backslash (\) before a newline character to indicate the continuation of the line, just like the shell script. This is our rule:

ACTION== "add", ATTRS {idProduct} = = "c52f"\, ATTRS {idVendor} = = "046d"\, ENV {DISPLAY} = ": 0"\, ENV {XAUTHORITY} = "/ run/user/1000/gdm/Xauthority"\, RUN+= "/ usr/bin/xinput-- disable 16"

Let's analyze this rule.

Operator

First, the operators that have been used and will be used are explained as follows:

= = and! = operator

= = is the equality operator, while! = is not equal to the operator. By using them, we can confirm that the keys applied to the rule match their respective values.

Assign operators = and: =

= is an assignment operator that is used to assign a value to a key. When we want to assign a value and want to make sure that it is not overridden by other rules, we need to use the: = operator instead, and with the value assigned by this operator, it cannot be changed.

+ = and-= operators

The + = and-= operators are each used to add or remove a value from a list of values defined by a specified key.

The keys we use

Now, let's analyze the keys we use in this rule. First, we have an ACTION key: by using it, when a specific event occurs on a device, we will specify the specific content of the rule we want to apply. Valid values are add, remove, and change.

Then, we use the ATTRS keyword to specify an attribute to match. We can use the udevadm info command to list a device attribute and provide its name or sysfs path:

Udevadm info-ap / devices/pci0000:00/0000:00:1d.0/usb2/2-1 devices/pci0000:00/0000:00:1d.0/usb2/2 2-1.2-1.2:1.1/0003:046D:C52F.0010/input/input39 Udevadm info starts with the device specified by the devpath and thenwalks up the chain of parent devices. It prints for every devicefound, all possible attributes in the udev rules key format.A rule to match, can be composed by the attributes of the deviceand the attributes from one single parent device. Looking at device'/ devices/pci0000:00/0000:00:1d.0/usb2/2-1 SUBSYSTEM== 2-1.2 phys 2-1.2 phys 1.1 Unique 0003 ATTR 046DF.0010: KERNEL== "input39" SUBSYSTEM== "input" DRIVER== "ATTR {name} =" Logitech USB Receiver "ATTR {phys} =" usb-0000:00:1d.0-1.2/input1 "ATTR {properties} =" 0 "ATTR {uniq} = "" looking at parent device'/ devices/pci0000:00/0000:00:1d.0/usb2/2-1 DRIVERS== ATTRS {country} = "00" looking at parent device'/ devices/pci0000:00/0000:00:1d.0/usb2/2-1 KERNELS== "2-1.2 DRIVERS== 1.1" SUBSYSTEMS== "usb" DRIVERS== "usbhid" ATTRS {authorized} = = "1" ATTRS {bAlternateSetting} = = "0" ATTRS {bInterfaceClass} = = "03" ATTRS {bInterfaceNumber} = = "01" ATTRS {bInterfaceProtocol} = = "00" ATTRS {bInterfaceSubClass} = "00" ATTRS {bNumEndpoints} = = "01" ATTRS {supports_ Autosuspend} = "1" looking at parent device'/ devices/pci0000:00/0000:00:1d.0/usb2/2-1 authorized 2-1.2: KERNELS== "2-1.2" SUBSYSTEMS== "usb" DRIVERS== "usb" ATTRS {authorized} = = "1" ATTRS {avoid_reset_quirk} = = "0" ATTRS {bConfigurationValue} = "1" ATTRS {bDeviceClass} = "00" ATTRS {bDeviceProtocol} = = "00" ATTRS { BDeviceSubClass} = "00" ATTRS {bMaxPacketSize0} = = "8" ATTRS {bMaxPower} = = "98mA" ATTRS {bNumConfigurations} = = "1" ATTRS {bNumInterfaces} = = "2" ATTRS {bcdDevice} = = "3000" ATTRS {bmAttributes} = = "a0" ATTRS {busnum} = "2" ATTRS {configuration} = = "RQR30.00_B0009" ATTRS {devnum} = "12" ATTRS {devpath} = = "1.2" ATTRS {idProduct} = = " C52f "ATTRS {idVendor} = =" 046d "ATTRS {ltm_capable} = =" no "ATTRS {manufacturer} = =" Logitech "ATTRS {maxchild} = =" 0 "ATTRS {product} = =" USB Receiver "ATTRS {quirks} = =" 0x0 "ATTRS {removable} =" removable "ATTRS {speed} = =" 12 "ATTRS {urbnum} =" 1401 "ATTRS {version} =" 2.00 "[...]

The above intercepts part of the output after running this command. As you can see from its output, udevadm starts with the specified path we provide and provides information about all parent devices. Note that the properties of the device are reported in the singular (for example, KERNEL), while its parent is in the plural (for example, KERNELS). Parent information can be part of the rule, but only one parent can be referenced at a time: mixing properties of different parent devices does not work. In the rules we defined above, we used a parent device attribute: idProduct and idVendor.

The next thing to do in our rule is to use the ENV keyword: it can be used to set or match environment variables. We assign values to DISPLAY and XAUTHORITY. These variables are necessary when we use the X server program to interact to set some required information: using the DISPLAY variable, we specify which machine the server is running on, which display and screen is used; and using XAUTHORITY provides a file path that contains Xorg authentication and authorization information. This file is usually located in the user's home directory.

*, we use the word RUN: it is used to run external programs. Very important: there is no immediate run here, but once all the rules are parsed, various actions will be run. In this case, we use the xinput utility to change the state of the touchpad. I don't want to explain the syntax of xinput here, which is beyond the scope of this article, just note that the ID of this touchpad is 16.

Once the rule is set, we can debug it by using the udevadm test command. This command is very useful for debugging and does not actually run the command specified by RUN:

$udevadm test-- action= "add" / devices/pci0000:00/0000:00:1d.0/usb2/2-1 1.2:1.1/0003:046D:C52F.0010/input/input39 2-1.2 1.2:1.1/0003:046D:C52F.0010/input/input39

What we provide to the command is the simulated action using the-- action option, as well as the sysfs path of the device. If no errors are reported, our rules work well. To use it in the real world, we need to reload the rules:

# udevadm control-reload

This command reloads the rule file, but it only has an effect on events that occur after the reload.

Thank you for reading this article carefully. I hope the article "how to write basic udev rules in Linux" shared by the editor will be helpful to you. At the same time, I also hope you will support us and pay attention to the industry information channel. More related knowledge is waiting for you to learn!

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.