Cover image for Linux Hotplug

Linux Hotplug

(Updated: )
Linux
, ,
Timeline

Timeline

2025-12-02

init

This article introduces the basic concepts, application scenarios, and underlying implementation mechanisms of hotplug in Linux systems. It discusses in detail the interaction process between the kernel and user space through uevent events, including the characteristics of device management tools such as devfs, mdev, and udev, as well as the kernel's use of the kobject_uevent() function to send events and a brief application of the udevadm command.

Linux Driver Notes

Table of ContentsLinks
1. Linux Driver Framework

Linux Driver Framework

https://even629.com/posts/2511093/

2. Linux Driver Loading Logic

Linux Driver Loading Logic

https://even629.com/posts/2511100/

3. Character Device Basics

Character Device Basics

https://even629.com/posts/2511113/

4. Concurrency and Race Conditions

Concurrency and Competition

https://even629.com/posts/2511123/

5. Advanced Character Device Progression

Advanced Character Device Progression

https://even629.com/posts/2511133/

6. Interrupts

Interrupts

https://even629.com/posts/2511143/

7. Platform Bus

Platform Bus

https://even629.com/posts/2511153/

8. Device Tree

Device Tree

https://even629.com/posts/2511300/

9. Device Model

Device Model

https://even629.com/posts/2512013/

10. Hot Plug

Hot Plug

https://even629.com/posts/2512023/

11. pinctrl Subsystem

pinctrl Subsystem

https://even629.com/posts/2512160/

12. GPIO Subsystem

gpio Subsystem

https://even629.com/posts/2512173/

13. Input Subsystem

Input Subsystem

https://even629.com/posts/2512183/

14. Single Bus

Single Bus

https://even629.com/posts/2512233/

15. I2C

I2C

https://even629.com/posts/2512283/

16. SPI

SPI

https://even629.com/posts/2512303/

17. UART

UART

https://even629.com/posts/2512313/

18. PWM

PWM

https://even629.com/posts/2601043/

19. RTC

RTC

https://even629.com/posts/2601053/

20. Watchdog

Watchdog

https://even629.com/posts/2601063/

21. CAN

CAN

https://even629.com/posts/2601093/

22. Network Device

Network Device

https://even629.com/posts/2601133/

23. ADC

ADC

https://even629.com/posts/2601143/

24. IIO

IIO

https://even629.com/posts/2602153

25. USB

USB

https://even629.com/posts/2602163

26. LCD

LCD

https://even629.com/posts/2602173

Hot Swap

**Hot swap refers to the ability to safely insert or remove hardware devices while the equipment is running, without shutting down or restarting the system.**This means you can insert or remove hardware components (such as USB devices, expansion cards, hard drives, etc.) on a computer or other electronic device without shutting down or interrupting ongoing operations.

The main purpose of hot swap is to provide convenience and flexibility. With hot swap, you can quickly replace or add hardware devices without stopping ongoing tasks. This is very useful in many scenarios, such as:

  1. USB devices: You can insert or remove USB devices such as mice, keyboards, printers, storage devices, etc., at any time without restarting the system.
  2. Hard drives: In some servers or storage systems, you can add or replace hard drives while running to expand storage capacity or replace faulty drives.
  3. Expansion cards: You can insert or remove expansion cards such as graphics cards, network cards, or sound cards on a computer to meet different needs or upgrade hardware performance.

To support hot-plug functionality, both hardware devices and the system must have the corresponding support. On the hardware side, device interfaces must be designed to allow insertion and removal without damaging the device or system. The system needs to provide appropriate drivers and management functions to correctly configure and recognize devices during insertion and removal.

The mechanism of hot-plug

Hot-plug is an interaction between the kernel and user space, achieved by calling user space programs (such ashotplug、udevandmdev). When the kernel needs to notify user space that a hot-plug event has occurred, it calls this user space program to implement the interaction.

In the Linux kernel, the hot-plug mechanism supports the dynamic insertion and removal of components such as USB devices, PCI devices, and even CPUs. This mechanism connects underlying hardware, kernel space, and user space programs, and has been continuously evolving and improving. The device file system is a mechanism for managing device files. In Linux, there are three common device file systems: devfs, mdev, and udev.

  • devfs: devfs is a kernel-based dynamic device file system that first appeared in Linux kernel 2.3.46. It handles device files by dynamically creating and managing device nodes. However, devfs had some limitations and performance issues, and was removed starting from Linux kernel 2.6.13.
  • mdev: mdev is alightweight hot-plug device user space program, commonly used in embedded Linux systems. It is a simplified version of udev, using theuevent_helpermechanism to handle device insertion and removal events. mdev calls the corresponding user program to create device nodes when a device is inserted.
  • udev: udev is currentlya widely used hot-plug device user space program on PCs. It is based on thenetlinkmechanism, listening to uevents sent by the kernel to handle device insertion and removal. udev can dynamically create and manage device nodes, and load appropriate drivers when a device is inserted. It provides rich configuration options, allowing users to flexibly manage device files.

Kernel sends events to user space

kobject_uevent()

kobject_ueventis a function in the Linux kernel used to generate and send uevent events. It is a way for udev and other device management tools to communicate with the kernel.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
// lib/kboject_uevent.c
/**
 * kobject_uevent - notify userspace by sending an uevent
 *
 * @kobj: struct kobject that the action is happening to
 * @action: action that is happening
 *
 * Returns 0 if kobject_uevent() is completed with success or the
 * corresponding error when it fails.
 */
int kobject_uevent(struct kobject *kobj, enum kobject_action action)
{
	return kobject_uevent_env(kobj, action, NULL);
}
EXPORT_SYMBOL_GPL(kobject_uevent);

Parameter description:

  • kobj: The kernel object (kobject) to send the uevent event
  • action: Indicates the action that triggers the uevent, which can be device insertion, removal, attribute change, etc. Below are some common action parameter values. These action types are used to describe different events occurring on the device. By passing the corresponding action type as the action parameter to thekobject_ueventfunction, the corresponding uevent event can be triggered to notify user-space udev to perform the corresponding operation.
    • KOBJ_ADD: Indicatesdevice addition or insertion operation, indicating adding an object to the kernel object system.
    • KOBJ_REMOVE: Indicatesdevice removal or extraction operation, indicating deleting an object from the kernel object system.
    • KOBJ_CHANGE: Indicatesdevice attribute modification operation, indicating changes to the kernel object, such as attribute modification, etc.
    • KOBJ_MOVE: Indicatesdevice movement operation, i.e., the device moves from one location to another.
    • KOBJ_ONLINE: indicatesdevice online operation, i.e., the device transitions from offline to online state, making it accessible.
    • KOBJ_OFFLINE: indicatesdevice offline operation, i.e., the device transitions from online to offline state, making it inaccessible.
    • KOBJ_BIND: indicatesattaching a device to a kernel object
    • KOBJ_UNBIND: indicatesdetaching a device from a kernel object
    • KOBJ_MAX: indicates the maximum value of an enumeration type, typically used to represent no operation.

kobject_ueventThe main function of this function is to generate a uevent event in the kernel and send it to user-space udev via the netlink mechanism. When this function is called, the kernel encapsulates the relevant device information and event type into a uevent message and sends it to user space through a netlink socket.

User-space udev receives these uevent messages and performs corresponding actions based on the device information and event type in the messages, such as creating or deleting device nodes, loading or unloading drivers, etc.

Example

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
#include <linux/init.h>
#include <linux/module.h>
#include <linux/slab.h>


struct kobject *mykobject01;
struct kset *mykset;
struct kobj_type mytype;


static int __init mykobj_uevent_init(void){
        int ret;

        // Create and add a kset
        mykset = kset_create_and_add("mykset", NULL, NULL);

        // Initialize and add a kobject to the kset
        mykobject01 = kzalloc(sizeof(*mykobject01), GFP_KERNEL);
        mykobject01->kset = mykset;
        ret = kobject_init_and_add(mykobject01, &mytype, NULL, "%s", "mykobject01");

        // Trigger a uevent event
        ret = kobject_uevent(mykobject01, KOBJ_CHANGE);
        
        return 0;
}


static void __exit mykobj_uevent_exit(void){
        kobject_put(mykobject01);
        kset_unregister(mykset);
}


module_init(mykobj_uevent_init);
module_exit(mykobj_uevent_exit);



MODULE_LICENSE("GPL");
MODULE_AUTHOR("even629<asqwgo@outlook.com>");
MODULE_DESCRIPTION("This is a test sample for kobject uevent");

udevadm command

udevadmis a command-line tool for interacting with the udev device manager. It provides a series of subcommands for querying and managing devices, triggering uevent events, and performing other udev-related operations. Some commonudevadmsubcommands and their functions are as follows:

  1. udevadm info: Used to obtain detailed information about a device, including device path, attributes, drivers, etc.
  2. udevadm monitor: Used to monitor and display uevent events in the current system. It shows device insertion, removal, and other related events in real time.
  3. udevadm trigger: Used to manually trigger uevent events for a device. This command can simulate device insertion, removal, etc., to trigger corresponding event handling.
  4. udevadm settle: Used to wait for udev to process all queued uevent events. It blocks until udev completes all current device processing operations.
  5. udevadm control: Used to interact with the udev daemon and control its behavior. For example, this command can reload udev rules, set log levels, etc.
  6. udevadm test: Used to test the matching and execution process of udev rules. This command can test whether a specific device correctly triggers the corresponding rules.

Test:

1
2
3
4
5
6
7
8
9
10
11
12
13
root@topeet:/root# udevadm monitor &
[1] 1561
root@topeet:/root# monitor will print the received events for:
UDEV - the event which udev sends out after rule processing
KERNEL - the kernel uevent


root@topeet:/root# insmod uevent_test.ko
KERNEL[1812.051745] change   /mykng out-of-tree module taints kernel.
                                 set/mykobject01 (mykset)
KERNEL[1812.056798] add      /module/uevent_test (module)
root@topeet:/root# UDEV  [1812.061846] change   /mykset/mykobject01 (mykset)
UDEV  [1812.068604] add      /module/uevent_test (module)

uevent is implemented based on kset

In the above driver code, ifRemoved the step of creating kset, user space cannot receive uevent events, analysis as follows:

kobject_uevent_env()

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
/**
 * kobject_uevent_env - send an uevent with environmental data
 *
 * @kobj: struct kobject that the action is happening to
 * @action: action that is happening
 * @envp_ext: pointer to environmental data
 *
 * Returns 0 if kobject_uevent_env() is completed with success or the
 * corresponding error when it fails.
 */
int kobject_uevent_env(struct kobject *kobj, enum kobject_action action,
		       char *envp_ext[])
{
	struct kobj_uevent_env *env;//Pointer to kobj_uevent_Pointer to the env structure, used to store the sent event and environment variables
	const char *action_string = kobject_actions[action];//Type of the event
	const char *devpath = NULL;//Stores the path of the kobject
	const char *subsystem;//Stores the name of the subsystem it belongs to
	struct kobject *top_kobj;//Pointer to the top-level top_kobj kobject
	struct kset *kset;//Pointer to kset, indicating the kset to which the kobject belongs
	const struct kset_uevent_ops *uevent_ops;//Pointer to struct kset_uevent_Pointer to the ops structure
	int i = 0;//Counter i, used to compile the environment variable array
	int retval = 0;//Indicates the execution result of the function, i.e., the return value

	/*
	 * Mark "remove" event done regardless of result, for some subsystems
	 * do not want to re-trigger "remove" event via automatic cleanup.
	 */
	if (action == KOBJ_REMOVE)//Check if the action is KOBJ_REMOVE, if so, set kobj->state_remove_uevent_sent is 1, indicating that the 'remove' event has been sent.
		kobj->state_remove_uevent_sent = 1;

	pr_debug("kobject: '%s' (%p): %s\n",
		 kobject_name(kobj), kobj, __func__);

	/* search the kset we belong to */
	top_kobj = kobj;
	while (!top_kobj->kset && top_kobj->parent)// Find the kset to which kobj belongs by looping until the top-level kobj of a specific valid kset is found, i.e., the root node of the kset.
		top_kobj = top_kobj->parent;

	if (!top_kobj->kset) {// If kobj has no kset, return directly.
		pr_debug("kobject: '%s' (%p): %s: attempted to send uevent "
			 "without kset!\n", kobject_name(kobj), kobj,
			 __func__);
		return -EINVAL;
	}

	kset = top_kobj->kset;
	uevent_ops = kset->uevent_ops;// The uevent_ops structure of the top-level kset.

	/* skip the event, if uevent_suppress is set*/
	if (kobj->uevent_suppress) {// Check kobj->uevent_Whether suppress is 1; if kobj->uevent is set_suppress, then output debug information indicating that the event is skipped.
		pr_debug("kobject: '%s' (%p): %s: uevent_suppress "
				 "caused the event to drop!\n",
				 kobject_name(kobj), kobj, __func__);
		return 0;
	}
	/* skip the event, if the filter returns zero. */
	if (uevent_ops && uevent_ops->filter)
		if (!uevent_ops->filter(kset, kobj)) {
			pr_debug("kobject: '%s' (%p): %s: filter function "
				 "caused the event to drop!\n",
				 kobject_name(kobj), kobj, __func__);
			return 0;
		}

	/* originating subsystem */
    	// According to uevent_The name field in ops obtains the name of the original subsystem. If uevent_ops->name exists, call the uevent_ops->name(kset, kobj) function to get the subsystem name; otherwise, use the name of the kset as the subsystem name.
	if (uevent_ops && uevent_ops->name)
		subsystem = uevent_ops->name(kset, kobj);
	else
		subsystem = kobject_name(&kset->kobj);
	if (!subsystem) {
		pr_debug("kobject: '%s' (%p): %s: unset subsystem caused the "
			 "event to drop!\n", kobject_name(kobj), kobj,
			 __func__);
		return 0;
	}

	/* environment buffer */
	env = kzalloc(sizeof(struct kobj_uevent_env), GFP_KERNEL);
	if (!env)
		return -ENOMEM;

	/* complete object path */
	devpath = kobject_get_path(kobj, GFP_KERNEL);
	if (!devpath) {
		retval = -ENOENT;
		goto exit;
	}

	/* default keys */
	retval = add_uevent_var(env, "ACTION=%s", action_string);
	if (retval)
		goto exit;
	retval = add_uevent_var(env, "DEVPATH=%s", devpath);
	if (retval)
		goto exit;
	retval = add_uevent_var(env, "SUBSYSTEM=%s", subsystem);
	if (retval)
		goto exit;

	/* keys passed in from the caller */
	if (envp_ext) {
		for (i = 0; envp_ext[i]; i++) {
			retval = add_uevent_var(env, "%s", envp_ext[i]);
			if (retval)
				goto exit;
		}
	}

	/* let the kset specific function add its stuff */
	if (uevent_ops && uevent_ops->uevent) {
		retval = uevent_ops->uevent(kset, kobj, env);
		if (retval) {
			pr_debug("kobject: '%s' (%p): %s: uevent() returned "
				 "%d\n", kobject_name(kobj), kobj,
				 __func__, retval);
			goto exit;
		}
	}

	switch (action) {
	case KOBJ_ADD:
		/*
		 * Mark "add" event so we can make sure we deliver "remove"
		 * event to userspace during automatic cleanup. If
		 * the object did send an "add" event, "remove" will
		 * automatically generated by the core, if not already done
		 * by the caller.
		 */
		kobj->state_add_uevent_sent = 1;
		break;

	case KOBJ_UNBIND:
		zap_modalias_env(env);
		break;

	default:
		break;
	}

	mutex_lock(&uevent_sock_mutex);
	/* we will send an event, so request a new sequence number */
    	// Add an environment variable named "SEQNUM" to the uevent environment variable list, and set its value
 	//to uevent_seqnum value plus 1. Here, add_uevent_var is an internal function used to add a key-value
	//pair to the uevent environment variable list. If the addition fails, the function returns a non-zero value and releases
	//uevent_sock_mutex lock and jump to the exit label for cleanup. The main function of this is to
	//add a unique sequence number to uevent events, so that their order can be identified when processing uevent events. In layman's
	//terms, each time an event is sent, it must have its own event number, which cannot be duplicated and will also be added to the environment variables.
	retval = add_uevent_var(env, "SEQNUM=%llu", ++uevent_seqnum);
	if (retval) {
		mutex_unlock(&uevent_sock_mutex);
		goto exit;
	}
	retval = kobject_uevent_net_broadcast(kobj, env, action_string,
					      devpath);// The kernel broadcasts a uevent event
	mutex_unlock(&uevent_sock_mutex);

#ifdef CONFIG_UEVENT_HELPER
	/* call uevent_helper, usually only enabled during early boot */
	if (uevent_helper[0] && !kobj_usermode_filter(kobj)) {
		struct subprocess_info *info;

		retval = add_uevent_var(env, "HOME=/");
		if (retval)
			goto exit;
		retval = add_uevent_var(env,
					"PATH=/sbin:/bin:/usr/sbin:/usr/bin");
		if (retval)
			goto exit;
		retval = init_uevent_argv(env, subsystem);
		if (retval)
			goto exit;

		retval = -ENOMEM;
		info = call_usermodehelper_setup(env->argv[0], env->argv,
						 env->envp, GFP_KERNEL,
						 NULL, cleanup_uevent_env, env);
		if (info) {
			retval = call_usermodehelper_exec(info, UMH_NO_WAIT);
			env = NULL;	/* freed by cleanup_uevent_env */
		}
	}
#endif

exit:
	kfree(devpath);
	kfree(env);
	return retval;
}
EXPORT_SYMBOL_GPL(kobject_uevent_env);

Because uevent is sent to user-space applications vianetlink socket, andnetlink socketis based on kset.

kobject_uevent_net_broadcastis a kernel function used to send a uevent event to all network namespaces in the system. Its parameters include:

  • kobjis the kernel object associated with the uevent event
  • envis a list containing uevent environment variables
  • action_stringis a string representing the type of the uevent event
  • devpathis a string representing the device path associated with the uevent event.

This function iterates through all network namespaces in the system and sends the uevent event to each network namespace. The main purpose of this function is to broadcast a uevent event within the kernel, so that user-space applications can receive and process these events.

Call the user-spaceuevent_helperprogram in the kernel to handle uevent events.uevent_helperis a user-space program that can be called when a uevent is generated in kernel space. IfCONFIG_UEVENT_HELPERmacro is defined, the kernel will call theuevent_helperprogram to handle these events in user space. In the above code, if theuevent_helpervariable is not empty and thekobj_usermode_filterfunction returns false, then thecall_usermodehelper_setupfunction is called to start a user-space process and pass the parameters in env to it. In this process, the parameters in env are converted into environment variables and passed to the user-space process.

In the function that creates a kset and adds it to the system, the second parameter is the passed uevent-related ops

1
2
3
extern struct kset * __must_check kset_create_and_add(const char *name,
					const struct kset_uevent_ops *u,
					struct kobject *parent_kobj);

struct kset_uevent_ops

Andstruct kset_uevent_opsis defined as follows

1
2
3
4
5
6
struct kset_uevent_ops {
	int (* const filter)(struct kset *kset, struct kobject *kobj);
	const char *(* const name)(struct kset *kset, struct kobject *kobj);
	int (* const uevent)(struct kset *kset, struct kobject *kobj,
		      struct kobj_uevent_env *env);
};

1.filterevent filter

  • Function: Determines whether toblocksending thekobjectuevent to user space.

  • Return value：

    • 0：Filter out(do not send uevent)
    • Non-0：Allow sending

  • Typical use：

    • Some internal devices do not require user space intervention;
    • Avoid triggering uevents for virtual devices (e.g., debugfs entries).

  • Example：

1
2
3
4
5
static int my_filter(struct kset *kset, struct kobject *kobj)
{
    /* If the device name starts with "internal_", do not notify user space */
    return strncmp(kobject_name(kobj), "internal_", 9) != 0;
}

2.nameSubsystem name provider

  • Function: Returns thekobjectto which the**“subsystem” name**, as in the ueventSUBSYSTEM=field.
  • Return value: string (e.g.,"usb","block","mybus"）。
  • Importance: User space (e.g., udev rules) often matches rules based onSUBSYSTEM.
  • Example：
1
2
3
4
static const char *my_name(struct kset *kset, struct kobject *kobj)
{
    return "mybus";  // All device uevents under this kset carry SUBSYSTEM=mybus
}

The corresponding uevent message will contain

1
2
3
4
ACTION=add
DEVPATH=/devices/mydevice
SUBSYSTEM=mybus   ← 来自此回调
...

Note: If not providednamecallback, the kernel defaults to usingkset->uevent_opstheksetname (usually the parent directory name).

3.ueventCustom environment variable injector

  • Function: Add custom key-value pairs to the uevent environment variable buffer (env)Add custom key-value pairs。

  • Parameters：

    • env: Type isstruct kobj_uevent_env, internally a string array (max 32 items, each 2048 bytes).

  • Call method: Useadd_uevent_var(env, "KEY=%s", value)。

  • Typical use：

    • Pass device attributes (e.g., vendor ID, serial number);
    • Trigger specific user-space logic.

  • Example

1
2
3
4
5
6
7
static int my_uevent(struct kset *kset, struct kobject *kobj,
                    struct kobj_uevent_env *env)
{
    add_uevent_var(env, "MYBUS_VERSION=1.0");
    add_uevent_var(env, "DEVICE_TYPE=sensor");
    return 0;
}

The corresponding uevent will contain

1
2
MYBUS_VERSION=1.0
DEVICE_TYPE=sensor

Example: Improve kset_uevent_ops structure

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
#include <linux/module.h>
#include <linux/init.h>
#include <linux/kobject.h>
#include <linux/slab.h>

struct kobject *mykobject01;
struct kobject *mykobject02;
struct kset *mykset;
struct kobj_type myktype;

int myfilter(struct kset *kset, struct kobject *kobj)
{
        if (strcmp(kobj->name, "mykobject01") == 0) {
                return 0; // Returning 0 means filtering out and not sending uevent
        }
        return 1;
}
const char *myname(struct kset *kset, struct kobject *kobj)
{
        return "my_kset";
}
int myuevent(struct kset *kset, struct kobject *kobj, struct kobj_uevent_env *env)
{
        add_uevent_var(env, "MYDEVICE=%s", "RK3568");
        return 0;
}

static struct kset_uevent_ops my_uevent_ops = {
        .filter = myfilter,
        .name = myname,
        .uevent = myuevent,
};

static int __init kset_uevent_ops_init(void)
{
        int ret = 0;
        // Create and add a kset
        mykset = kset_create_and_add("mykset", &my_uevent_ops, NULL);

        // Create kobject01
        mykobject01 = kzalloc(sizeof(*mykobject01), GFP_KERNEL);
        mykobject01->kset = mykset;
        ret = kobject_init_and_add(mykobject01, &myktype, NULL, "mykobject01");

        // Create kobject02
        mykobject02 = kzalloc(sizeof(*mykobject02), GFP_KERNEL);
        mykobject02->kset = mykset;
        ret = kobject_init_and_add(mykobject02, &myktype, NULL, "mykobject02");

        // Trigger uevent event
        ret = kobject_uevent(mykobject01, KOBJ_ADD);
        ret = kobject_uevent(mykobject02, KOBJ_ADD);

        return ret;
}

static void __exit kset_uevent_ops_exit(void)
{
        kobject_put(mykobject01);
        kobject_put(mykobject02);
        kset_unregister(mykset);
}

module_init(kset_uevent_ops_init);
module_exit(kset_uevent_ops_exit);

MODULE_LICENSE("GPL");
MODULE_AUTHOR("even629<asqwgo@outlook.com>");
MODULE_DESCRIPTION("This is a test sample for kset_uevent_ops");

Test:

1
2
3
4
5
6
7
8
9
10
11
root@topeet:/root# udevadm monitor &
[1] 1341
root@topeet:/root# monitor will print the received events for:
UDEV - the event which udev sends out after rule processing
KERNEL - the kernel uevent
root@topeet:/root# insmod kset_uevent_ops_test.ko
[  170.300220] kset_uevent_ops_test: loading out-of-tree module taintsKERNEL[167.589323] add       /mykset/mykobject02 (my_ksekt)
eKERNEL[167.594449] add      /module/kset_uevent_ops_test (module)
root@topneet:/root# UDEV  [167.600297] add      /myeksetl/mykobject02 (my_kset)
e)EV  [167.60.7308] add      /module/kset_uevent_ops_test (modul

Netlink is a mechanism in the Linux kernelused for duplex communication between the kernel and user space. Itis based on the socket communication mechanism, and provides a reliable, asynchronous, multicast, and ordered communication method.

The main features of the Netlink mechanism include:

  1. Duplex communication: Netlink allows bidirectional communication between the kernel and user space, enabling the kernel to send messages to user space and also receive messages from user space.
  2. Reliability: Netlink provides a reliable message delivery mechanism, ensuring message integrity and reliability. It uses acknowledgment and retransmission mechanisms to guarantee reliable transmission.
  3. Asynchronous Communication: Netlink supports asynchronous communication, meaning the kernel and user space can send and receive messages independently without synchronously waiting for each other’s response.
  4. Multicast Support: Netlink allows broadcasting messages to multiple processes or sockets to achieve one-to-many communication.
  5. Ordered Transmission: Netlink guarantees ordered transmission of messages, meaning messages are received at the receiving end in the order they were sent.

Netlink has a wide range of applications, common ones include:

  1. System administration tools: Tools such as ifconfig and ip use Netlink to communicate with the kernel to obtain and configure network interface information.
  2. Inter-process communication: Processes can use Netlink for cross-process communication to achieve data exchange and coordination between processes.
  3. Communication between kernel modules and user-space applications: Kernel modules can send notifications to or receive instructions from user-space applications via Netlink.
Creating a Socket

In Linux socket programming, creating a socket is the first step in building a network application. A socket can be understood as a bridge between the application and the network, used for sending, receiving, and processing data over the network. The prototype of this system call and the required header files are as follows:

Header filesFunction prototype
#include<sys/types.h>
#include<sys/socket.h>		int socket(int domain, int type, int protocol);

domainThe parameter specifies the protocol family of the socket

The protocol family specifies the type of protocol used by the socket. Common protocol families includeAF_INET、AF_INET6、AF_UNIXetc. Among them:

  • AF_INETIndicates the IPv4 protocol family
  • AF_INET6Indicates the IPv6 protocol family
  • AF_UNIXIndicates the Unix domain protocol family
  • AF_NETLINKIndicates the Netlink protocol family.

typeThe parameter specifies the type of the socket

The socket type specifies the data transmission method of the socket. Common socket types includeSOCK_STREAM、SOCK_DGRAM、SOCK_RAWetc. Among them:

  • SOCK_STREAMIndicates a connection-oriented stream socket, mainly used for reliable data transmission, such as the TCP protocol.
  • SOCK_DGRAMIndicates a connectionless datagram socket, mainly used for unreliable data transmission, such as the UDP protocol.
  • SOCK_RAWIndicates a raw socket, which can directly access the underlying network protocol.

protocolThe parameter specifies the specific protocol used by the socket. The meanings of these three parameters are introduced below:

The protocol type specifies the specific protocol type used by the socket. Common protocol types includeIPPROTO_TCP、IPPROTO_UDP、IPPROTO_ICMPetc. Among them:

  • IPPROTO_TCPIndicates the TCP protocol
  • IPPROTO_UDPIndicates the UDP protocol
  • IPPROTO_ICMPIndicates the ICMP protocol
  • NETLINK_KOBJECT_UEVENTIndicates the NETLINK_KOBJECT protocol

The following code will be used to create a new socket

1
int socket_fd = socket(AF_NETLINK, SOCK_RAW, NETLINK_KOBJECT_UEVENT);
  • AF_NETLINK: Specifies the use of the Netlink protocol family. The Netlink protocol family is a Linux-specific protocol family used for communication between the kernel and user space.
  • SOCK_RAW: Specifies the creation of a raw socket. This socket type can directly access the underlying protocol without protocol stack processing. In this case, we can directly use the Netlink protocol for communication.
  • NETLINK_KOBJECT_UEVENT: Specifies a type of Netlink protocol, namely the kobject uevent type. kobject uevent is used for event notifications related to kernel objects. When a kobject object in the kernel changes, user space is notified via this type of Netlink message.
Binding the socket
Required header filesFunction prototype
#include<sys/types.h>
#include<sys/socket.h>		int bind(int sockfd, const struct sockaddr *addr,socklen_t addrlen);

  • sockfdParameter: specifies the socket descriptor to be bound,

  • addrParameter: specifies the address information to be bound, here usingstruct sockaddr_nlstructure,struct sockaddr_nlThe definition of the structure is as follows:

    1
    2
    3
    4
    5
    6
    struct sockaddr_nl {
    	sa_family_t nl_family; // AF_NETLINK
      	unsigned short nl_pad; // zero
      	uint32_t nl_pid; // port ID
      	uint32_t nl_groups;// multicast groups mask
    };

    • nl_family: indicates the address family, here fixed toAF_NETLINK, indicating the use of the Netlink protocol family.

    • nl_pad: padding field, set to 0. Used for byte alignment within the structure.

    • nl_pid: Port ID, set to 0 to indicate allocation by the kernel.

    • nl_groups: multicast group mask, used to specify the multicast groups of interest. When set to 1, it indicates that the user-space process will only receive kernel events from the basic group of kernel events. This means the user-space process will only receive kernel events belonging to the basic group and not events from other multicast groups.

  • addrlenParameter: the addrlen parameter is an integer specifying the byte length of the structure pointed to by addr. It is used to ensure correct parsing of the size of the structure passed to the addr parameter.

Example

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
{
	...
	struct sockaddr_nl nl; // Define a pointer nl pointing to a struct sockaddr_nl structure
	bzero(&nl, sizeof(struct sockaddr_nl));// Clear the memory area pointed to by nl to zero, ensuring the structure's fields are initialized to 0
	nl.nl_family = AF_NETLINK;// Set the nl of the nl structure_family field to AF_NETLINK, specifying the address family as Netlink
	nl.nl_pid = 0;// Set the nl_pid field of the nl structure to 0, indicating that the target process ID is 0, meaning broadcast to all processes
	nl.nl_groups = 1;// Set the nl_groups field of the nl structure to 1, indicating that only kernel events of the basic group are received
	
	// Use the bind function to bind the socket_fd socket to the nl address structure
	ret = bind(socket_fd, (struct sockaddr *)&nl, sizeof(struct sockaddr_nl));

	if (ret < 0) {
		printf("bind error\n");
		return -1;
	}
	...
}
Receive data

Netlink sockets do not need to call the listen function when receiving data; instead, they can directly use the recv function for reception.

Required header filesFunction prototype
#include<sys/types.h>
#include<sys/socket.h>		ssize_t recv(int sockfd, void *buf, size_t len, int flags);

Function parameters:

  • sockfd: Specifies the socket descriptor, i.e., the Netlink socket from which to receive data.
  • buf: Pointer to the data reception buffer, used to store the received data.
  • len: Specifies the byte size of the data to be read.
  • flags: Specifies some flags to control the data reception method. Typically, it can be set to 0.

Return value:

  • On success, returns the actual number of bytes read.
  • If the return value is 0, it indicates that the other party has closed the connection.
  • If the return value is -1, it indicates an error occurred. You can check the errno variable to obtain the specific error code.

Using the recv function, data can be received from the specified Netlink socket and stored in the provided buffer. The return value of the function indicates the actual number of bytes read, which can be used to determine whether data was successfully received.

Example code:

1
2
3
4
5
6
7
8
9
10
while (1) {
	bzero(buf, 4096); // Clear the buffer buf to zero to ensure initialization before data reception
	len = recv(socket_fd, &buf, 4096, 0);// Receive data from the socket_fd socket and store it in the buffer buf, with a maximum reception of 4096 bytes
	for (i = 0; i < len; i++) {
		if (*(buf + i) == '\0') {// If there is a '\0' character in the received data, replace it with '\n' to display a newline when printing
			buf[i] = '\n';
		}
	}
	printf("%s\n", buf);// Print the received data
}
Example code
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/socket.h>
#include <sys/types.h>
#include <linux/netlink.h>
#include <unistd.h>

#define UEVENT_BUF_SIZE 8192

int main(int argc, char *argv[])
{
        int ret;
        int len = 0, i = 0;
        int socket_fd;
        char buf[UEVENT_BUF_SIZE] = { 0 };        
        struct sockaddr_nl nl = {
                .nl_family = AF_NETLINK,
                .nl_pid = 0, // Port ID allocated by the kernel (usually set to 0 in user space)
                .nl_groups = 1, // Only receive kernel events belonging to the basic group
        };

        socket_fd = socket(AF_NETLINK, SOCK_RAW, NETLINK_KOBJECT_UEVENT);
        if (socket_fd < 0) {
                perror("socket");
                exit(EXIT_FAILURE);
        }
        ret = bind(socket_fd, (const struct sockaddr *)&nl, sizeof(struct sockaddr_nl));
        if (ret < 0) {
                perror("bind");
                close(socket_fd);
                exit(EXIT_FAILURE);
        }

        printf("Listening for uevents...\n");

        while (1) {
                memset(buf, 0, sizeof(buf));
                len = recv(socket_fd, buf, sizeof(buf), 0);
                if (len < 0) {
                        perror("recv");
                        break;
                }

                for (i = 0; i < len && i < sizeof(buf) - 1; i++) {
                        if (*(buf + i) == '\0') {
                                buf[i] = '\n';
                        }
                }
                buf[len] = '\0'; // Ensure character termination

                printf("\n--- Uevent Received ---\n%s", buf);
        }

        close(socket_fd);
        return 0;
}

Test:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
root@topeet:/root# ./netlink_test.o &
[1] 2275
root@topeet:/root# Listening for uevents...
root@topeet:/root# insmod kset_uevent_ops_test.ko
--- Uevent Received ---
add@/mykset/mykobject02
ACTION=add
DEVPATH=/mykset/mykobject02
SUBSYSTEM=my_kset
MYDEVICE=RK3568
SEQNUM=3288

--- Uevent Received ---
root@topeet:/root# add@/module/kset_uevent_ops_test
ACTION=add
DEVPATH=/module/kset_uevent_ops_test
SUBSYSTEM=module
SEQNUM=3289

uevent_helper

Inkobject_uevent_env()the function:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
#ifdef CONFIG_UEVENT_HELPER
	/* call uevent_helper, usually only enabled during early boot */
	if (uevent_helper[0] && !kobj_usermode_filter(kobj)) {
		struct subprocess_info *info;

		retval = add_uevent_var(env, "HOME=/");
		if (retval)
			goto exit;
		retval = add_uevent_var(env,
					"PATH=/sbin:/bin:/usr/sbin:/usr/bin");
		if (retval)
			goto exit;
		retval = init_uevent_argv(env, subsystem);
		if (retval)
			goto exit;

		retval = -ENOMEM;
		info = call_usermodehelper_setup(env->argv[0], env->argv,
						 env->envp, GFP_KERNEL,
						 NULL, cleanup_uevent_env, env);
		if (info) {
			retval = call_usermodehelper_exec(info, UMH_NO_WAIT);
			env = NULL;	/* freed by cleanup_uevent_env */
		}
	}
#endif

Line 3 is an if expression that checksuevent_helperwhether the first element of the array is true. And calls thekobj_usermode_filterfunction for user-mode filtering,uevent_helperdefined as follows:

1
char uevent_helper[UEVENT_HELPER_PATH_LEN] = CONFIG_UEVENT_HELPER_PATH;

CONFIG_UEVENT_HELPER_PATHis a macro defined in the kernel source code’sinclude/generated/autoconf.hfile, as shown below:

1
#define CONFIG_UEVENT_HELPER_PATH ""

This macro is empty, so to enable theuevent_helperfunction, you need to enable it in the graphical configuration interfaceCONFIG_UEVENT_HELPERmacro to enableuevent_helperandCONFIG_UEVENT_HELPER_PATHmacro to set the defaultuevent_helperpath (such as/sbin/mdev）；

uevent_helper configuration method 1

1
2
3
4
5
6
7
8
9
10
11
Device Drivers
	Generic Driver Options
		[*] Support for uevent helper // Select
		(/sbin/mdev) path to uevent helper // Set mdev path
		
File systems
	Pseudo filesystems.
		[*]/proc file system support // Selected
		[*] Sysctl support(/proc/sys) // Selected

[*]Networking support // Selected

Save configuration:

1
2
3
cp .config arch/arm64/configs/rockchip_linux_defconfig
../build.sh kernel
cp boot.img ~/tftp

In configuration 1 above, setuevent helperand the corresponding path. This is configuration method 1, but this method requires recompiling the kernel, which is cumbersome to use. Besides method 1, there are faster methods 2 and 3:

uevent_helper configuration method 2

Regardless of whetherCONFIG_UEVENT_HELPER_PATHis configured, after system startup, you can use the following command to setuevent_helper：

1
echo /sbin/mdev > /sys/kernel/uevent_helper

This will setuevent_helperto/sbin/mdev。

uevent_helper configuration method 3

Regardless of whetherCONFIG_UEVENT_HELPER_PATHis configured, after system startup, you can use the following command to setuevent_helper：

1
echo /sbin/mdev > /proc/sys/kernel/hotplug

This will setuevent_helperset to/sbin/mdev。

It should be noted that configuration method 2 and configuration method 3 depend on the above configurationSupport for uevent helper,File systemsandNetworkingoptions, and the values already written in configuration method 1 can be modified through configuration method 2 and configuration method 3. For/proc/sys/kernel/hotplugand/sys/kernel/uevent_helperreading and writing are both for performing read and write operations on the uevent_helper attribute.

/sys/kernel/uevent_helperis a file in the sysfs filesystem, which is theuevent_helperinterface of the attribute. By performing read and write operations on this file, the value of the uevent_helper attribute can be read or modified. In the kernel source code’skernel/ksysfs.cdirectory, the definition and related implementation of theuevent_helperattribute can be found, and the specific content is as follows:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
// kernel/ksysfs.c
#ifdef CONFIG_UEVENT_HELPER
/* uevent helper program, used during early boot */
static ssize_t uevent_helper_show(struct kobject *kobj,
				  struct kobj_attribute *attr, char *buf)
{
	return sprintf(buf, "%s\n", uevent_helper);
}
static ssize_t uevent_helper_store(struct kobject *kobj,
				   struct kobj_attribute *attr,
				   const char *buf, size_t count)
{
	if (count+1 > UEVENT_HELPER_PATH_LEN)
		return -ENOENT;
	memcpy(uevent_helper, buf, count);
	uevent_helper[count] = '\0';
	if (count && uevent_helper[count-1] == '\n')
		uevent_helper[count-1] = '\0';
	return count;
}
KERNEL_ATTR_RW(uevent_helper);
#endif

  • uevent_helper_showfunction is used to write the value ofuevent_helperinto buf and return the number of characters written.

  • uevent_helper_storefunction is used to copy the value in buf touevent_helperand process it as needed, then return the number of characters written.

/proc/sys/kernel/hotplugis a virtual file used to configure the hotplug event handler in the kernel. By performing write operations on this file, theuevent_helpervalue of the attribute. In the kernel source code’skernel/sysctl.cfile, you can see that thehotplugoperation is actually performed onuevent_helper.

1
2
3
4
5
6
7
8
9
10
// kernel/sysctl.c`
#ifdef CONFIG_UEVENT_HELPER
	{
		.procname	= "hotplug",
		.data		= &uevent_helper,
		.maxlen		= UEVENT_HELPER_PATH_LEN,
		.mode		= 0644,
		.proc_handler	= proc_dostring,
	},
#endif

This code defines a file namedhotplugfor handling uevent events. It is associated with theuevent_helperattribute.

  • .procnamerepresents the file name, i.e.,/proc/hotplug。
  • .datais a pointer to theuevent_helperstructure, used to store data related to the file. This pointer points to theuevent_helperstructure for handling uevent events.
  • .maxlenrepresents the maximum length of the file, i.e., the maximum length of the file content. This value isUEVENT_HELPER_PATH_LEN, indicating the maximum length of the file content.
  • .moderepresents the file access permissions. This value is 0644, meaning the file’s permissions are-rw-r--r--, i.e., all users can read the file, but only the root user can write to it.

Example

Calling user-spaceuevent_helperprogram to handle uevent events.

uevent_helperis a user-space program that can be called when a uevent event is generated in kernel space. IfCONFIG_UEVENT_HELPERthe macro is defined, the kernel will calluevent_helperprogram to handle these events in user space.
Inkobject_uevent_env()the function, ifuevent_helpervariable is not null andkobj_usermode_filterfunction returns false, thencall_usermodehelper_setupfunction is called to start a user-space process and pass the parameters in env to it. In this process, the parameters in env are converted into environment variables and passed to the user-space process.

1
2
3
4
5
6
7
8
9
10
11
12
13
#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <unistd.h>
int main(int argc, char *argv[])
{
	int fd = open("/dev/ttyFIQ0", O_WRONLY);
	dup2(fd, STDOUT_FILENO);
	printf("SUBSYSTEM is %s\n", getenv("SUBSYSTEM"));
	return 0;
}

Method 2:

1
2
3
4
5
6
7
8
root@topeet:/root# echo /root/uevent_helper_test.o > /sys/kernel/uevent_helper
root@topeet:/root# insmod kset_uevent_ops_test.ko
[   63.445449] kset_uevent_ops_test: loading out-of-tree module taints kernel.
root@topeet:/root# SUBSYSTEM is my_kset
SUBSYSTEM is module
root@topeet:/root# rmmod kset_uevent_ops_test.ko
SUBSYSTEM is my_kset
SUBSYSTEM is module

Method 3:

1
2
3
4
5
6
7
root@topeet:/root# echo /root/uevent_helper_test.o > /proc/sys/kernel/hotplug
root@topeet:/root# insmod kset_uevent_ops_test.ko
root@topeet:/root# SUBSYSTEM is module
SUBSYSTEM is my_kset
root@topeet:/root# rmmod kset_uevent_ops_test.ko
SUBSYSTEM is module
SUBSYSTEM is my_kset

It can be seen that both of the above configurations can print theSUBSYSTEMenvironment variable passed during kernel loading.

Mount USB flash drives and TF cards using udev

Configure buildroot to support udev

1
2
3
4
5
6
System configuration
	/dev management (Dynamic using devtmpfs + eudev) -->
		( ) Static using device table
                ( ) Dynamic using devtmpfs only
                ( ) Dynamic using devtmpfs + mdev
                (X) Dynamic using devtmpfs + eudev

Mount USB flash drive

To use udev for automatic mounting of USB flash drives, you also need to/etc/udev/rules.dcreate corresponding rule files in the directory

1
2
KERNEL=="sd[a-z][0-9]", SUBSYSTEM=="block", ACTION=="add", RUN+="/etc/udev/rules.d/usb/usb-add.sh %k"
SUBSYSTEM=="block", ACTION=="remove", RUN+="/etc/udev/rules.d/usb/usb-remove.sh
  • KERNEL=="sd[a-z][0-9]
    • KERNEL: indicates matching the kernel name of the device.
    • sd[a-z][0-9]: is a regular expression pattern,
      • sd: indicates the device name starts with “sd”
      • [a-z]: indicates the third character of the device name is a lowercase letter
      • [0-9]: indicates the fourth character of the device name is a digit.

This pattern is used to match block device nodes of USB storage devices, such as/dev/sda1、/dev/sdb2etc.

  • SUBSYSTEM=="block"
    • SUBSYSTEM: indicates matching the subsystem name of the device.
    • block: indicates the device’s subsystem is the block device subsystem, i.e., devices related to disks, partitions, etc. This part of the rule ensures that only devices under the block device subsystem are matched.
  • ACTION=="add"andACTION=="remove"
    • ACTION: Indicates the action of matching the device.
      • add: Indicates that the device is added.
      • remove: Indicates that the device is removed.

This part of the rules is for handling events where devices are added and removed.

  • RUN+="/etc/udev/rules.d/usb/usb-add.sh %k
    • RUN+="...": Indicates executing the specified command on the matched device.
    • "/etc/udev/rules.d/usb/usb-add.sh": Is the path of the command to be executed, i.e., execute when the device is added/etc/udev/rules.d/usb/usb-add.shscript file.
    • %k: Is a variable provided by udev, representing the kernel name of the matched device

When a block device is added, execute/etc/udev/rules.d/usb/usb-add.shscript, when a block device is removed, execute/etc/udev/rules.d/usb/usb-remove.shscript

  • /etc/udev/rules.d/usb/usb-add.shThe content is as follows

    1
    2
    #!/bin/sh
    /bin/mount -t vfat /dev/$1 /mnt
    • /bin/mount: Calls the mount command (explicitly specifying the full path).
    • -t vfat: Specifies the file system type to be mounted as VFAT (i.e., FAT32 or FAT16, commonly used for USB drives, SD cards, etc.).
    • /dev/ $ 1: Represents the device file, where$ 1is the first argument passed to the script or command line.

  • /etc/udev/rules.d/usb/usb-remove.shThe content is as follows

    1
    2
    3
    #!/bin/sh
    sync
    /bin/umount -l /mnt
    • -l: Indicates “lazy unmount”. It immediately removes the mount point from the filesystem namespace, but actual cleanup (such as releasing the device) is deferred until the device is no longer busy (no processes are using it). Commonly used when a device is “busy” and cannot be unmounted normally (for example, when a shell is currently in the/mntdirectory).

Then grant execute permissions to these two scripts

1
chmod a+x /etc/udev/rules.d/usb/usb-add.sh /etc/udev/rules.d/usb/usb-remove.sh

Mount the TF card

/etc/udev/rules.d/In the directory, create a file named002.rulesfile

1
2
KERNEL=="mmcblk[0-9]p[0-9]", SUBSYSTEM=="block", ACTION=="add", RUN+="/etc/udev/rules.d/tf/tf-add.sh %k"
SUBSYSTEM=="block", ACTION=="remove", RUN+="/etc/udev/rules.d/tf/tf-remove.sh"
  • KERNEL=="mmcblk[0-9]p[0-9]"
    • KERNEL: Indicates matching the kernel name of the device.
    • "mmcblk[a-z][0-9]": Is a regular expression pattern
      • mmcblk: Indicates that the device name starts with"mmcblk"at the beginning
      • [0-9]: Indicates that the 7th and 9th characters of the device name are digits.

This pattern is used to match block device nodes of TF card storage devices, such as/dev/mmcblk1p1, etc.

  • SUBSYSTEM=="block"
    • SUBSYSTEM: Indicates the subsystem name of the matching device.
    • "block": Indicates that the device’s subsystem is the block device subsystem, i.e., devices related to disks, partitions, etc.

This part of the rule is to ensure that only devices under the block device subsystem are matched.

  • ACTION=="add"andACTION=="remove"
    • ACTION: Indicates the action of the matching device.
      • "add": Indicates that the device is added.
      • "remove": Indicates that the device is removed.

This part of the rule is to handle events of device addition and removal.

  • RUN+="/etc/udev/rules.d/tf/tf-add.sh %k"
    • RUN+="...": Indicates executing the specified command on the matching device.
    • "/etc/udev/rules.d/tf/tf-add.sh": Is the path of the command to be executed, i.e., execute when the device is added/etc/udev/rules.d/tf/tf-add.shscript file.
    • %k: Is a variable provided by udev, representing the kernel name of the matching device.

When the TF card block device is added, it will execute/etc/udev/rules.d/usb/tf-add.shscript, and when the TF card block device is removed, it will execute/etc/udev/rules.d/tf/tf-remove.shscript

In/etc/udev/rules.d/usb/tf-add.shwrite the following content to the file:

1
2
#!/bin/sh
/bin/mount -t vfat /dev/$1 /mnt

In/etc/udev/rules.d/usb/tf-remove.shwrite the following content to the file

1
2
3
#!/bin/sh
sync
/bin/umount -l /mnt

Then grant execute permissions to these two scripts

1
chmod a+x /etc/udev/rules.d/usb/tf-add.sh /etc/udev/rules.d/usb/tf-remove.sh`

Use mdev to mount USB drives and TF cards

Configure buildroot to support mdev

1
2
make rockchip_rk3568_defconfig
make menuconfig

The configuration is as follows:

1
2
3
4
5
6
System configuration
	/dev management (Dynamic using devtmpfs + eudev) -->
		( ) Static using device table
                ( ) Dynamic using devtmpfs only
                (X) Dynamic using devtmpfs + mdev
                ( ) Dynamic using devtmpfs + eudev

In addition to configuring buildroot, you also need to configure the relevant options of busybox, because buildroot uses busybox

1
make busybox-menuconfig

The configuration is as follows:

1
2
3
4
5
Linux System Utilities
	[*] mdev (17 kb)
	[*]   Support /etc/mdev.conf
	[*]     Support subdirs/symlinks
	[ ]       Support regular expressions substitutions when renaming device

Mount USB drive

Similar to udev, mdev also needs to add corresponding rules. The difference is that mdev uses/etc/mdev.conffile to configure the rules and behavior of the mdev tool. To use mdev to automatically mount USB drives, you need to add to the/etc/mdev.conffile the following two rules

1
2
sd[a-z][0-9] 0:0 666 @/etc/mdev/usb_insert.sh
sd[a-z] 0:0 666 $/etc/mdev/usb_remove.sh

These two rules are used to handle hotplug events of USB drives and execute corresponding actions. In/etc/mdev.confIn the file, each line is a rule with the following format:

1
<设备节点正则表达式> <设备的所有者:设备的所属组> <设备的权限> <设备插入或移除时需要执行的命令>

Below is a detailed introduction to the above two rules:

  • sd[a-z][0-9]is a regular expression pattern used to match device nodes starting with “sd”, followed by a lowercase letter and a digit, for example/dev/sda1etc.
  • 0:0 666indicates setting the owner and permissions of the device node. 0:0 means the user ID and group ID of the owner and group are both 0, i.e., root user. 666 means the permissions are readable and writable.
  • @/etc/mdev/usb_insert.shindicates that when a device matching the rule is inserted, mdev will execute/etc/mdev/usb_insert.shscript.@symbol indicates that a shell command is executed.
  • $/etc/mdev/usb_remove.shindicates that when a device matching the rule is removed, mdev will execute/etc/mdev/usb_remove.shscript.$symbol indicates that an internal command is executed.

/etc/mdev/usb_insert.shand/etc/mdev/usb_remove.shThe two files are shown in the following figure:

  • /etc/mdev/usb_insert.sh
1
2
3
4
5
6
#!/bin/sh

if [ -d /sys/block/*/$MDEV ]; then
	mount /dev/$MDEV /mnt
	sync
fi
  • /etc/mdev/usb_remove.sh
1
2
3
#!/bin/sh
sync
/bin/umount -l /mnt

Then grant execution permissions to these two scripts

1
chmod a+x /etc/mdev/usb_insert.sh /etc/mdev/usb_remove.sh

Mount TF card

to/etc/mdev.confadd the following two rules to the file

1
2
mmcblk[0-9]p[0-9] 0:0 666 @/etc/mdev/tf_insert.sh
mmcblk[0-9] 0:0 666 $/etc/mdev/tf_remove.sh
  • mmcblk[0-9]p[0-9]is a regular expression pattern used to match TF card block devices starting with"mmcblk", such as/dev/mmcblk1p1etc.
  • 0:0 666indicates setting the owner and permissions of the device node.0:0indicates that the user ID and group ID of the owner and group are both 0, i.e., the root user.666indicates that the permissions are readable and writable.
  • @/etc/mdev/tf_insert.shindicates that when a device matching the rule is inserted, mdev will execute the/etc/mdev/tf_insert.shscript.@symbol indicates that a shell command is being executed.
  • $/etc/mdev/tf_remove.shindicates that when a device matching the rule is removed, mdev will execute the/etc/mdev/tf_remove.shscript.$symbol indicates that an internal command is being executed.

/etc/mdev/tf_insert.shand/etc/mdev/tf_remove.shas shown below

  • /etc/mdev/tf_insert.sh
1
2
3
4
5
#!/bin/sh
if [ -d /sys/block/*/$MDEV ]; then
	mount /dev/$MDEV /mnt
	sync
fi
  • /etc/mdev/tf_remove.sh
1
2
3
#!/bin/sh
sync
/bin/umount -l /mnt

Then grant execution permissions to these two scripts

1
chmod a+x /etc/mdev/tf_insert.sh /etc/mdev/tf_remove.sh

Fix the device node of USB devices

Requirement

In Linux systems, when using multiple USB-to-serial devices, it is common to encounter unstable device nodes due to changes in the order of plugging and unplugging USB-to-serial devices. To solve this problem, we can use udev to fix the device nodes, ensuring that the device nodes are not affected by the order of plugging and unplugging USB-to-serial devices

Solution

Insert USB device:

1
udevadm info -a -n /dev/ttyUSB0

udevadm info -a -n /dev/ttyUSB0is a command used to obtain detailed information about a specific device node, including device attributes, drivers, device paths, etc. The meanings of the parameters of these commands are as follows:

  • -a: Display all attributes associated with the specified device node.
  • -n: Specify the path or name of the device node.

udevadm info -a -n /dev/ttyUSB0
udevadm info -a -n /dev/ttyUSB0

The output of this command may include the following information:

  1. Device path (DEVPATH): The path of the device in the system, for example/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2/2-1.2:1.0/ttyUSB0/tty/ttyUSB0。
  2. Device node (DEVNAME): The node of the device in the file system, i.e./dev/ttyUSB0。
  3. Device attributes: Including the device’s vendor ID, product ID, serial number, etc.
  4. Device driver: The name and path of the driver used by the device.
  5. Device type (SUBSYSTEM):usb

Next, in the development board’setc/udev/rules.d/directory, create a rule file named 001.rules:

1
KERNELS==”5-1:1.0”,SUBSYSTEMS==”usb”,MODE:=”0777”,SYMLINK+=”myusb”

  1. KERNELS=="5-1:1.0"

    • Match the device’skernel device name

    • 5-1:1.0is the path identifier of the USB device in the kernel:

      • 5: USB bus number
      • 1: USB device number
      • 1.0: Interface number, indicating the 0th endpoint of the 1st interface
      • This value comes from theudevadm infooutput’sKERNELSfield

  2. SUBSYSTEMS=="usb"

    • Match the device’ssubsystem

    • indicates that this is a USB type device

    • Can be used to filter all USB devices

  3. MODE:="0777"

    • Set thepermissions (mode)
  • 0777means:
    • All users (root, regular users, and others) have read, write, and execute permissions
    • That is:rwxrwxrwx, so any program can directly access the device (e.g.,/dev/ttyUSB0）

⚠️ Note:MODEbefore is:=, not==。:=means “assignment”, while==is “matching”.

  1. SYMLINK+="myusb"

    • Create asymbolic link

    • For example, the original device is/dev/ttyUSB0, now there will be an additional soft link:/dev/myusb -> /dev/ttyUSB0

    • You can usemyusbto replacettyUSB0, making naming and script invocation more convenient

Effect
Effect