OpenWRT Hotplug原理分析

最新推荐文章于 2025-04-15 14:05:57 发布
转载 最新推荐文章于 2025-04-15 14:05:57 发布 · 2.4k 阅读 · 19 ·
CC 4.0 BY-SA版权
原文链接：https://github.com/wywincl/hotplug
文章标签：

#linux #网络 #openwrt #hotplug #udev

OpenWRT Hotplug原理分析

本次研究基于OpenWRT 14_07 trunk。其他版本有部分差异，请阅读时注意。

目录表

  1. Hotplug原理
  2. Hotplug应用
  3. 参考

Hotplug原理

Hotplug即热插拔，在新版本OpenWRT上，hotplug，coldplug与watchdog等被集成到全新的Procd系统中。

Procd是OpenWRT下新的预初始化，初始化，热插拔和事件系统。在openwrt 中, procd 作为 init 进程会处理许多事情, 其中就包括 hotplug。procd本身并不知道如何处理hotplug事件，也没有必要知道，因为它只实现机制，而不实现策略。事件的处理是由配置文件决定的，这些配置文件即所谓的rules.。老版本下独立的hotplug2在r36987被移除了。所以下面我们要介绍的就是新版本下Hotplug的机制。

要了解Hotplug运行的整个过程，首先得了解procd系统的工作流程。才能从全局了解hotplug是如何工作的。在这里我们重点介绍与hotplug相关的procd启动过程。

Procd启动过程分析

preinit()函数
void
preinit(void)
{
	char *init[] = { "/bin/sh", "/etc/preinit", NULL };
	char *plug[] = { "/sbin/procd", "-h", "/etc/hotplug-preinit.json", NULL };

	LOG("- preinit -\n");

	plugd_proc.cb = plugd_proc_cb;
	plugd_proc.pid = fork();
	if (!plugd_proc.pid) {
		execvp(plug[0], plug);
		ERROR("Failed to start plugd\n");
		exit(-1);
	}
	if (plugd_proc.pid <= 0) {
		ERROR("Failed to start new plugd instance\n");
		return;
	}
	uloop_process_add(&plugd_proc);

	setenv("PREINIT", "1", 1);

	preinit_proc.cb = spawn_procd;
	preinit_proc.pid = fork();

	if (!preinit_proc.pid) {
		execvp(init[0], init);
		ERROR("Failed to start preinit\n");
		exit(-1);
	}
	if (preinit_proc.pid <= 0) {
		ERROR("Failed to start new preinit instance\n");
		return;
	}
	uloop_process_add(&preinit_proc);

	DEBUG(4, "Launched preinit instance, pid=%d\n", (int) preinit_proc.pid);
}

  1. 创建子进程执行/etc/preinit脚本，此时PREINIT环境变量被设置为1，主进程同时使用uloop_process_add()把/etc/preinit子进程加入uloop进行监控，当/etc/preinit执行结束时回调plugd_proc_cb()函数把监控/etc/preinit进程对应对象中pid属性设置为0，表示/etc/preinit已执行完成。

  2. 创建子进程执行/sbin/procd -h /etc/hotplug-preinit.json，主进程同时使用uloop_process_add()把/sbin/procd子进程加入uloop进行监控，当/sbin/procd进程结束时回调spawn_procd()函数。

  3. spawn_procd()函数繁衍后继真正使用的/sbin/procd进程，从/tmp/debuglevel读出debug级别并设置到环境变量DBGLVL中，把watchdog fd设置到环境变量WDTFD中，最后调用execvp()繁衍/sbin/procd进程。

procd进程

在这里我们主要分析procd的五个状态,分别为 STATE_EARLY、STATE_INIT、STATE_RUNNING、STATE_SHUTDOWN、STATE_HALT，这5个状态将按顺序变化，当前状态保存在全局变量state中，可通过procd_state_next()函数使用状态发生变化。

static void state_enter(void)
{
	char ubus_cmd[] = "/sbin/ubusd";

	switch (state) {
	case STATE_EARLY:
		LOG("- early -\n");
		watchdog_init(0);
		hotplug("/etc/hotplug.json");
		procd_coldplug();
		break;

	case STATE_INIT:
		// try to reopen incase the wdt was not available before coldplug
		watchdog_init(0);
		LOG("- ubus -\n");
		procd_connect_ubus();

		LOG("- init -\n");
		service_init();
		service_start_early("ubus", ubus_cmd);

		procd_inittab();
		procd_inittab_run("respawn");
		procd_inittab_run("askconsole");
		procd_inittab_run("askfirst");
		procd_inittab_run("sysinit");
		break;

	case STATE_RUNNING:
		LOG("- init complete -\n");
		break;

	case STATE_SHUTDOWN:
		LOG("- shutdown -\n");
		procd_inittab_run("shutdown");
		sync();
		break;

	case STATE_HALT:
		LOG("- reboot -\n");
		reboot(reboot_event);
		break;

	default:
		ERROR("Unhandled state %d\n", state);
		return;
	};
}
  • STATE_EARLY状态 - init前准备工作
    1. 初始化watchdog
    2. 根据"/etc/hotplug.json"规则监听hotplug
    3. procd_coldplug()函数处理，把/dev挂载到tmpfs中，fork udevtrigger进程产生冷插拔事件，以便让hotplug监听进行处理
    4. udevstrigger进程处理完成后回调procd_state_next()函数把状态从STATE_EARLY转变为STATE_INIT
  • STATE_INIT状态 - 初始化工作
    1. 连接ubusd，此时实际上ubusd并不存在，所以procd_connect_ubus函数使用了定时器进行重连，而uloop_run()需在初始化工作完成后才真正运行。当成功连接上ubusd后，将注册service main_object对象，system_object对象、watch_event对象(procd_connect_ubus()函数)，
    2. 初始化services（服务）和validators（服务验证器）全局AVL tree
    3. 把ubusd服务加入services管理对象中(service_start_early)
    4. 根据/etc/inittab内容把cmd、handler对应关系加入全局链表actions中
    5. 顺序加载respawn、askconsole、askfirst、sysinit命令
    6. sysinit命令把/etc/rc.d/目录下所有启动脚本执行完成后将回调rcdone()函数把状态从STATE_INIT转变为STATE_RUNNING
  • STATE_RUNNING状态
    1. 进入STATE_RUNNING状态后procd运行uloop_run()主循环

Hotplug原理图

Hotplug原理的整个流程如下所示：

-----------------------
|    procd daemon     |
|    (hotplug.json)   |
-----------------------
		  netlink| socket			user space
-------------------------------------------------
				 |				    kernel space
-----------------------
|    (uevent [json])  |
|    kernel           |
-----------------------

主要过程分为以下两个部分：

  1. 内核发出uevent事件

内核使用uevent事件通知用户空间，uevent首先在内核中调用netlink_kernel_create()函数创建一个socket套接字，该函数原型在netlink.h中定义。这是一种特殊类型的socket ，专门用于内核空间与用户空间的异步通信。
kobject_uevent()产生uevent事件(/lib/kobject_uevent.c)，事件的部分信息通过环境变量传递，如$ACTION, $DEVPATH, $SUBSYSTEM等，产生的uevent先由netlink_broadcast_filtered()发出，最后调用uevent_helper[]所指定的程序来处理。
在linux中，uevent_helper[]里默认指定”/sbin/hotplug”，但可以通过/sys/kernel/uevent_helper（kernel/ksysfs.c）或/proc/kernel/uevent_helper(kernel/sysctl.c)来修改成指定的程序。
在新OpenWRT中，并不使用user_helper[]指定程序来处理uevent（/sbin/hotplug不存在，在以前版本中存在），而是通过PF_NETLINK套接字来获取来自内核空间的uevent。

  1. 用户空间监听uevent

在proc/plug/hotplug.c中，创建一个PF_NETLINK套接字来监听内核netlink_broadcast_filtered()发出的uevent。收到uevent之后，在根据/etc/hotplug.json里的描述，定位到对应的执行函数来处理。
通常情况下，/etc/hotplug.json会调用/sbin/hotplug-call来处理uevent，它根据uevent的$SUBSYSTEM变量来分别调用/etc/hotplug.d下不同目录中的脚本。
/sbin/hotplug-call脚本如下所示，这里面的$1表示hotplug-call的第一个参数：

root@OpenWrt:/sbin# cat hotplug-call 
#!/bin/sh
# Copyright (C) 2006-2010 OpenWrt.org

export HOTPLUG_TYPE="$1"

. /lib/functions.sh

PATH=/bin:/sbin:/usr/bin:/usr/sbin
LOGNAME=root
USER=root
export PATH LOGNAME USER
export DEVICENAME="${DEVPATH##*/}"

[ \! -z "$1" -a -d /etc/hotplug.d/$1 ] && {
        for script in $(ls /etc/hotplug.d/$1/* 2>&-); do (
                [ -f $script ] && . $script
        ); done
}

下表是hotplug.json的具体内容，重点关注蓝色字段。

root@OpenWrt:/etc# cat hotplug.json 

[
        [ "case", "ACTION", {
                "add": [
                        [ "if",
                                [ "and",
                                        [ "has", "MAJOR" ],
                                        [ "has", "MINOR" ],
                                ],
                                [
                                        [ "if",
                                                [ "or",
                                                        [ "eq", "DEVNAME",
                                                                [ "null", "full", "ptmx", "zero" ],
                                                        ],
                                                        [ "regex", "DEVNAME",
                                                                [ "^gpio", "^hvc" ],
                                                        ],
                                                ],
                                                [
                                                        [ "makedev", "/dev/%DEVNAME%", "0666" ],
                                                        [ "return" ],
                                                ]
                                        ],
                                        [ "if",
                                                [ "or",
                                                        [ "eq", "DEVNAME", "mapper/control" ],
                                                        [ "regex", "DEVPATH", "^ppp" ],
                                                ],
                                                [
                                                        [ "makedev", "/dev/%DEVNAME%", "0600" ],
                                                        [ "return" ],
                                                ],
                                        ],
                                        [ "if",
                                                [ "has", "DEVNAME" ],
                                                [ "makedev", "/dev/%DEVNAME%", "0644" ],
                                        ],
                                ],
                        ],
                        [ "if",
                                [ "has", "FIRMWARE" ],
                                [
                                        [ "exec", "/sbin/hotplug-call", "%SUBSYSTEM%" ],
                                        [ "load-firmware", "/lib/firmware" ],
                                        [ "return" ]
                                ]
                        ],
                ],
                "remove" : [
                        [ "if",
                                [ "and",
                                        [ "has", "DEVNAME" ],
                                        [ "has", "MAJOR" ],
                                        [ "has", "MINOR" ],
                                ],
                                [ "rm", "/dev/%DEVNAME%" ]
                        ]
                ]
        } ],
        [ "if",
                [ "eq", "SUBSYSTEM", "platform" ],
                [ "exec", "/sbin/hotplug-call", "%SUBSYSTEM%" ]
        ],
        [ "if",
                [ "and",
                        [ "has", "BUTTON" ],
                        [ "eq", "SUBSYSTEM", "button" ],
                ],
                [ "exec", "/etc/rc.button/%BUTTON%" ]
        ],
        [ "if",
                [ "eq", "SUBSYSTEM",
                        [ "net", "input", "usb", "ieee1394", "block", "atm", "zaptel", "tty", "button" ]
                ],
                [ "exec", "/sbin/hotplug-call", "%SUBSYSTEM%" ]
        ],
        [ "if",
                [ "and",
                        [ "eq", "SUBSYSTEM", "usb-serial" ],
                        [ "regex", "DEVNAME",
                                [ "^ttyUSB", "^ttyACM" ]
                        ],
                ],
                [ "exec", "/sbin/hotplug-call", "tty" ]
        ],
]

[⬆]

Hotplug应用

U盘的自动挂载卸载

Hotplug一个常见的实例应用就是U盘或SD卡等外设的自动挂载和卸载功能。所以这里我们主要介绍如何利用hotplug实现U盘，移动硬盘等外设自动挂载的方法和原理。本文中的例子还需要根据实际情况作相应适配。

当然，首先得内核有相应的驱动程序支持才行。当U盘插入后，会产生uevent事件，hotplug收到这个内核广播事件后，根据uevent 事件json格式的附带信息内容，在hotplug.json中进行定位。事件包含的信息一般为如下所示：

ACTION(add), DEVPATH(devpath), SUBSYSTEM(block), MAJOR(8), MINOR(1), DEVNAME(devname), DEVTYPE(devtype), SEQNUM(865)

根据上面的信息，就可以在hotplug.json中定位到两个条目，如上面hotplug.json中蓝色显示字段。第一个条目执行的是makedev，该命令会创建设备节点。第二个条目会根据附带信息中的ACTION, DEVPATH, SUBSYSTEM, DEVNAME, DEVTYPE 等变量，调用命令exec去执行hotplug-call脚本。

于是 hotplug-call 会尝试执行 /etc/hotplug.d/block/ 目录下的所有可执行脚本。

所以我们可以在这里放置我们的自动挂载/卸载处理脚本。
例如，编写/etc/hotplug.d/block/30-usbmount,填入以下内容实现U盘自动挂载，卸载：

#!/bin/sh
 
[ "$SUBSYSTEM" = block ] || exit0
[ "$DEVTYPE" = partition -a"$ACTION" = add ] && {
    echo"$DEVICENAME" | grep 'sd[a-z][1-9]' || exit 0
    test-d /mnt/$DEVICENAME || mkdir /mnt/$DEVICENAME
    mount  -o iocharset=utf8,rw /dev/$DEVICENAME/mnt/$DEVICENAME || \
        mount-o rw /dev/$i /mnt/$i
}
 
[ "$DEVTYPE" = partition -a"$ACTION" = remove ] && {
    echo"$DEVICENAME" | grep 'sd[a-z][1-9]' || exit 0
    umount/mnt/$DEVICENAME && rmdir /mnt/$DEVICENAME
}

Button按键的检测

在OpenWRT中，按键的检测也是通过Hotplug机制来实现的。

它首先写了一个内核模块：gpio_button_hotplug, 用于监听按键，有中断和 poll 两种方式。然后在发出事件的同时, 将记录并计算得出的两次按键时间差也作为 uevent 变量发出来。这样在用户空间收到这个 uevent 事件时就知道该次按键按下了多长时间。

hotplug.json 中有描述, 如果 uevent 中含有 BUTTON 字符串, 而且 SUBSYSTEM 为 “button”, 则执行/etc/rc.button/下的 %BUTTON% 脚本来处理。

细节描述如下：
当按键时，则触发button_hotplug_event函数（gpio-button-hotplug.c）

调用button_hotplug_create_event产生uevent事件，调用button_hotplug_fill_event填充事件(JSON格式)，并最终调用button_hotplug_work发出uevent广播。

上述广播，被守护进程procd中的hotplug_handler (procd/plug/hotplug.c) 收到，并根据etc/hotplug.json中预先定义的JSON内容匹配条件，定位到对应的执行函数，具体如下所示，命中了两个条目，所以会依次执行这两个条目队列中的操作函数：

[ "if",
	[ "and",
		[ "has", "BUTTON" ],
		[ "eq", "SUBSYSTEM", "button" ],
	],
	[ "exec", "/etc/rc.button/%BUTTON%" ]
],
和
[ "if",
	[ "eq", "SUBSYSTEM",
	[ "net", "input", "usb", "ieee1394", "block", "atm", "zaptel", "tty", "button" ]
	],
	[ "exec", "/sbin/hotplug-call", "%SUBSYSTEM%" ]
],

在rc.button目录下，我们定义了reset按钮的执行脚本：

root@OpenWrt:/etc/rc.button# cat reset
#!/bin/sh

[ "${ACTION}" = "released" ] || exit 0

. /lib/functions.sh

logger "$BUTTON pressed for $SEEN seconds"

if [ "$SEEN" -lt 1 ]
then
        echo "REBOOT" > /dev/console
        sync
        reboot
elif [ "$SEEN" -gt 5 ]
then
        echo "FACTORY RESET" > /dev/console
        jffs2reset -y && reboot &
fi

从脚本中我们可以清晰地看出，当按键时间小于1s时，执行reboot重启命令，当按键时间超过5s时，执行恢复出厂设置并重启命令。

第二个条目，由于默认情况下没有在/etc/hotplug.d目录下创建button子目录，因此执行为空。

使用 export DBGLVL=10; procd -h /etc/hotplug.json 截获一些打印信息看看:

root@OpenWrt:/etc/rc.button# export DBGLVL=10; procd -h /etc/hotplug.json
procd:hotplug_handler_debug(404): {{"HOME":"\/","PATH":"\/sbin:\/bin:\/usr\/sbin:\/usr\/bin","SUBSYSTEM":"button","ACTION":"pressed","BUTTON":"reset","SEEN":"42949450","SEQNUM":"331"}}
procd: rule_handle_command(355): Command: exec
procd: rule_handle_command(357):  /etc/rc.button/reset
procd: rule_handle_command(358): 
procd: rule_handle_command(360): Message:
procd: rule_handle_command(362):  HOME=/
procd: rule_handle_command(362):  PATH=/sbin:/bin:/usr/sbin:/usr/bin
procd: rule_handle_command(362):  SUBSYSTEM=button
procd: rule_handle_command(362):  ACTION=pressed
procd: rule_handle_command(362):  BUTTON=reset
procd: rule_handle_command(362):  SEEN=42949450
procd: rule_handle_command(362):  SEQNUM=331
procd: rule_handle_command(363): 
procd: queue_next(281): Launched hotplug exec instance, pid=987
procd: rule_handle_command(355): Command: exec
procd: rule_handle_command(357):  /sbin/hotplug-call
procd: rule_handle_command(357):  button
procd: rule_handle_command(358): 
procd: rule_handle_command(360): Message:
procd: rule_handle_command(362):  HOME=/
procd: rule_handle_command(362):  PATH=/sbin:/bin:/usr/sbin:/usr/bin
procd: rule_handle_command(362):  SUBSYSTEM=button
procd: rule_handle_command(362):  ACTION=pressed
procd: rule_handle_command(362):  BUTTON=reset
procd: rule_handle_command(362):  SEEN=42949450
procd: rule_handle_command(362):  SEQNUM=331
procd: rule_handle_command(363): 
procd: queue_proc_cb(286): Finished hotplug exec instance, pid=987
...

接口状态检测

当接口状态出现ifup或者ifdown时，netifd守护进程会调用call_hotplug（）（/interface-event.c）来处理这个事件，call_hotplug()执行run_cmd（）,并且设置系统环境变量$ACTION, $INTERFACE, $DEVICE, 同时调用hotplug_cmd_path(=DEFAULT_HOTPLUG_PATH=/sbin/hotplug-call, 在netifd.h中)并传入参数iface。下表是上述变量的介绍。

---------------------------------------------------------------
变量名称				|				说明
---------------------------------------------------------------
ACTION                事件，如ifup,ifdown,ifupdate
---------------------------------------------------------------
INTERFACE       	  发生事件动作的接口名，如（wan, ppp0）
---------------------------------------------------------------
DEVICE                发生事件动作的物理接口名，如（eth0.1或br-lan）
---------------------------------------------------------------

这样用户空间脚本hotplug-call就会将/etc/hotplug.d/iface目录下的所有脚本执行一遍。

举例说明：

我们在iface目录下编写一个脚本名字叫13-my-action, 内容如下：

root@OpenWrt:/etc/hotplug.d/iface# cat 13-my-action 
#!/bin/sh

[ "$ACTION" = ifup ] && {
  echo Device:$DEVICE  Action:$ACTION "13-my-action" > /dev/console
}

让接口down，从下面的log中可以看出，iface下的自定义脚本被执行了一遍。

root@OpenWrt:/etc/hotplug.d/iface# ubus call network.interface.lan up

[  462.370000] IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready
[  462.370000] device eth1 entered promiscuous mode
[  462.380000] IPv6: ADDRCONF(NETDEV_UP): br-lan: link is not ready
Device:br-lan Action:ifup 13-my-action
[  462.980000] eth1: link up (1000Mbps/Full duplex)
[  462.980000] br-lan: port 1(eth1) entered forwarding state
[  462.990000] br-lan: port 1(eth1) entered forwarding state
[  462.990000] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
[  463.040000] IPv6: ADDRCONF(NETDEV_CHANGE): br-lan: link becomes ready
procd: Not starting instance igmpproxy::instance1, an error was indicated
[  464.990000] br-lan: port 1(eth1) entered forwarding state

[备注] 由于守护进程netifd在ubus中注册了服务，因此我们可以通过ubus调用netifd提供的服务接口，例如使接口ifdown命令为： ubus call network.interface.lan up/down。

早期Hotplug2

早期的Hotplug机制，单独运行守护进程，内核会指定hotplug2进程来处理系统内核广播出来的uevent事件。原理和上面介绍的大同小异，hotplug2采用了与linux中的udev相同的rule编写规则。

[⬆]

参考

https://openwrt.org/

openwrt热插拔HotPlug
锅锅的博客
12-14 5372
一、介绍 热插拔，就是 当触发器事件触发时，Procd 将按字母顺序执行该触发器目录/etc/hotplug.d/中的所有脚本 比如u盘插入拔出 网络断开，或者连接上 等等 官方文档链接 二、原理 在/etc/hotplug.d目录中，您会发现一些目录block、iface、net和ntp。 当触发器事件触发时，Procd 将按字母顺序执行该触发器目录中的所有脚本 1、可作为触发的源 目录 描述 block 块设备事件：设备连接/断开 button： 默认情况下不创建，看到/etc/rc.button
OpenWrt Hotplug 浅析
peihuas的博客
08-26 1772
procd/plug/hotplug.c中, 创建一个 PF_NETLINK 套接字来监听内核 netlink_broadcast() 发出的 uevent. 收到 uevent 之后, 再根据 /etc/hotplug.json 里的描述定位到对应的执行函数来处理。通常情况下，/etc/hotplug.json会调用/sbin/hotplug-call来处理uevent，它根据uevent的$SUBSYSTEM变量来分别调用/etc/hotplug.d下不同目录中的脚本。Hotplug，直译就是热插拔。
openwrt hotplug
weixin_30305735的博客
11-24 302
由内核发出 event 事件. kobject_uevent() 产生 uevent 事件(lib/kobject_uevent.c 中), 产生的 uevent 先由 netlink_broadcast_filtered() 发出, 最后调用 uevent_helper[] 所指定的程序来处理. uevent_helper[] 里默认指定 "/sbin/hotplug", 但可以通过 /sys...
OpenWRT 学习笔记-14 hotplug机制
我思故我在！
07-14 1326
ubus是用户态 hotplug机制是linux内核提供的一种消息通知机制，主要用来实现内核态事件向用户态传递。OpenWrt下的ubus也类似，一个是用户态的，而hotplug是内核态的，其功能都是用来消息传递。linux早期的hotplug机制并没有现在这么复杂，在2.4内核的时候只是针对usb、pci子系统，只是简单的hotplug调用进程，后面才使用netlink机制来实现通知机制。当时我主要用hotplug机制来实现usb 3g网卡的模式转换（配合usbmodswitch），现在hotp...
hotplug:OpenWRT 的热插拔工具
06-13
OpenWRT Hotplug原理分析 本次研究基于OpenWRT 14_07 trunk。其他版本有部分差异，请阅读时注意。 Hotplug即热插拔，在新版本OpenWRT上，hotplug，coldplug与watchdog等被集成到全新的Procd系统中。 Procd是OpenWRT下新的预初始化，初始化，热插拔和事件系统。在openwrt 中, procd 作为 init 进程会处理许多事情, 其中就包括 hotplug。procd本身并不知道如何处理hotplug事件，也没有必要知道，因为它只实现机制，而不实现策略。事件的处理是由配置文件决定的，这些配置文件即所谓的rules.。老版本下独立的hotplug2在r36987被移除了。所以下面我们要介绍的就是新版本下Hotplug的机制。 要了解Hotplug运行的整个过程，首先得了解procd系统的工作流程。才能从全局了解hotp
OPENWRT 教程第八章 OpenWrt 挂载U盘 扩展篇OpenWRT Hotplug原理分析
09-19 1942
目录表 Hotplug原理 Hotplug应用 参考 Hotplug原理 Hotplug即热插拔，在新版本OpenWRT上，hotplug，coldplug与watchdog等被集成到全新的Procd系统中。 Procd是OpenWRT下新的预初始化，初始化，热插拔和事件系统。在openwrt中,procd作为init进程会处理许多事情, 其中就包括hot...
【openwrt】【procd】Openwrt系统启动流程分析
分享嵌入式Linux技术知识
01-06 3397
在Openwrt系统中执行ps命令可以看到 1号进程就是procd但实际上内核启动完成后，运行的第一个用户进程并不是procd,在运行procd之前还执行了其他准备工作，换句话说，procd并不一开始就是“老大”，它只是最终接替了老大的位置。
openwrt subdir函数分析
to_be_better_wen的博客
04-22 1328
openwrt subdir函数分析
40 --＞ OpenWrt 路由系统 gpio-button-hotplug 与 内核模块gpio-button-hotplug 之间关系
weixin_38387929的博客
08-09 2293
gpio-keys-polled 驱动裁剪注意事项 内核模块的 “gpio-keys-polled”,驱动位于drivers/input/keyboard/ 路径下, 路由系统的 “gpio-keys-polled”,驱动位于 openWrt源码的 package/kernel/gpio-button-hotplug/路径下, 由此得出 内核模块与路由系统的"gpio-keys-polled"是互斥,因此我们选择路由系统的gpio-keys-polled驱动, 保证路由系统功能完整性。 gpio-keys-
OpenWrt热插拔HotPlug
hzlarm的博客
11-12 8516
热插拔官方文档 当某些 events事件发生时，Procd（init系统和进程管理守护进程）会执行位于/etc/hotplug.d/中的脚本，例如当接口启动或关闭时，检测到新的存储驱动器时，或者按下按钮时. 当使用PPPoE连接或者在不稳定的网络中，或使用硬件按钮时非常有用。 该功能模块模拟/扩展了已淘汰的Hotplug2软件包的功能。 工作原理 在 /etc/hotplug.d 文件夹包含了...
hotplug 介绍
03-19
openwrt 的hotplug 功能介绍，详细说明流程、功能和使用方法
[Openwrt]procd实现hotplug机制介绍
l00102795的博客
03-09 1131
uevent_helper[] 里默认指定 "/sbin/hotplug", 但可以通过 /sys/kernel/uevent_helper (kernel/ksysfs.c) 或 /proc/kernel/uevent_helper (kernel/sysctl.c) 来修改成指定的程序.在 OpenWrt 并不使用 user_helper[] 指定程序来处理 uevent (/sbin/hotplug 不存在), 而是使用 PF_NETLINK 来获取来自内核的 uevent.
openwrt USB热插拔(hotplug)
板蓝根蜀黍的博客
04-23 4973
目录 前言 一、hotplug相关子目录 block 文件夹 注意：etc/hotplug.d文件不存在怎么办 二、用法 2.示例 总结 前言 openwrt USB外挂U盘的时候很需要热插拔功能 openwrt官网传送门 当某些事件发生时，Procd（init系统和进程管理守护进程）执行位于/etc/hotplug.d/中的脚本，例如当接口启动或关闭时，检测到新的存储驱动器时，或者按下按钮时. 当使用PPPoE连接或者在不稳定的网络中，或使用硬件按钮时非常有用。 该功能模块...
linux hotplug 机制,佐须之男的博客- 跟着佐大学Lede/OpenWrt开发入门培训班讲义-18 OpenWrt hotplug 机制分析...
weixin_28668743的博客
05-14 493
备注：此文是佐须之男"跟着佐大学OpenWrt开发"入门培训班教学视频演讲稿提纲，虽是内部资料但再三考虑后对外公布，通过公众的监督来鞭策自己。如对完整内容感兴趣，可以参加"跟着佐大学OpenWrt开发"入门培训班：http://www.forgotfun.org/2018/04/openwrt-training-2018.html。课程试听地址：hotplug机制是linux内核提供的一种消息通知...
11-Openwrt hotplug system
szembed的博客
09-06 390
hotplug为linux的一个热拔插系统，在很多应用都有用到，如网口的拔插，USB的拔插，按键的触发…非常广泛的应用，下面举几个例子来进行理解这个过程。
OpenWrt中的热拔插Hotplug.d中的脚本
最新发布
weixin_58779966的博客
04-15 588
这些脚本根据不同的事件类型被组织在不同的子目录下，当相应事件发生时，系统会自动调用这些脚本。：热插拔机制，用于在设备或接口状态发生变化时（如插入、拔出、网络连接状态改变等），自动触发相应的处理动作。脚本可以根据这些环境变量获取事件的详细信息，并执行相应的处理逻辑。每个脚本在执行时，会接收到一系列与事件相关的环境变量，如。：主目录，包含多个子目录，每个子目录对应一类事件。子目录，并按字母顺序执行该子目录下的所有脚本。：处理块设备（如USB存储设备）的事件。：处理网络接口的事件。：处理无线设备的事件。
Openwrt firewall hotplug
weixin_58458700的博客
05-10 677
解决问题之前需要大致了解什么是hotplug，有一个比较简单的概念才好下手。在很多嵌入式设备中，都有着hotplug(热插拔)的身影，热插拔可以帮助设备更快更稳定的处理和维护设备节点。有 2 个不同角度来看待热插拔：从内核角度看，热插拔是在硬件、内核和内核驱动之间的交互。从用户角度看，热插拔是内核和用户空间之间，通过调用用户空间程序（如hotplug、udev 和 mdev）的交互。当需要通知用户内核发生了某种热插拔事件时，内核才调用这个用户空间程序。
热插拔机制
无敌电工
11-16 928
热插拔：hotplug / uevent机制
openwrt热插拔机制
03-25
<think>嗯，用户想了解OpenWRT系统的热插拔机制实现原理和配置方法，特别是与udev的关系。首先，我需要回忆一下OpenWRT的基本架构。记得OpenWRT使用Procd作为其初始化系统，而Procd整合了hotplug、coldplug等功能。用户提供的引用中提到，新版本的OpenWRT将hotplug等集成到Procd中，所以可能需要解释Procd和传统udev的区别和联系。 接下来，热插拔机制的原理。根据引用内容，udev在用户态处理内核发送的热插拔事件，而OpenWRT可能使用自己的方式。需要确认OpenWRT是否完全使用Procd来替代udev，还是两者结合。引用3提到hotplug处理驱动程序后调用udevd生成设备文件，但可能在OpenWRT中流程不同，因为Procd可能接管了部分功能。 然后是配置方法，用户可能需要知道如何添加自定义规则。在udev中，规则文件通常在/etc/udev/rules.d/，但OpenWRT可能路径不同，或者使用其他机制。比如，Procd的hotplug脚本可能在/etc/hotplug.d/目录下，分不同子目录如block、net等，处理不同类型设备的事件。 还要考虑用户的实际需求，他们可能希望自动挂载U盘或配置网络设备。需要提供具体的配置示例，比如挂载U盘的脚本，可能需要用到block hotplug，编写脚本检查设备类型并执行mount命令。 此外，引用中提到的冷插拔处理，即开机时已连接的设备，OpenWRT如何处理？可能需要通过触发事件或查询sysfs来生成设备节点，确保这些设备在启动后被正确识别。 最后，验证配置的方法，比如使用logger记录日志，或者查看/dev/下的设备文件是否存在。可能还需要提醒用户注意权限问题，尤其是在自动挂载时的用户权限设置。 总结下来，回答的结构应该包括原理、组件分析、配置步骤、示例和验证方法，同时引用提供的资料来支持每个部分。确保使用正确的术语，比如Procd、hotplug.d目录、udev规则等，并区分OpenWRT与传统Linux发行版的不同之处。</think>### OpenWRT热插拔机制实现与配置分析 #### 一、实现原理 1. **Procd系统集成** OpenWRT从2014年起采用全新的Procd系统，将热插拔（hotplug）、冷插拔（coldplug）和守护进程管理等功能整合到统一框架中[^1]。与传统Linux的udev不同，Procd通过精简设计更适配嵌入式场景。 2. **事件传递流程** - 内核检测到设备变动时，通过netlink发送事件到用户态 - Procd的hotplug模块接收事件并解析 - 通过/etc/hotplug.d/目录下的脚本响应事件[^3] 3. **与udev的差异** OpenWRT未直接使用udev，但保留了类似机制： ```shell # 设备规则路径 /etc/dev.d/ # 设备事件处理脚本 /sys/class/ # 设备信息接口 ``` #### 二、核心配置方法 1. **脚本挂载点配置** ```shell /etc/hotplug.d/ ├── block/ # 存储设备事件 ├── net/ # 网络设备事件 └── usb/ # USB设备事件 ``` 示例U盘自动挂载脚本（/etc/hotplug.d/block/10-mount）： ```bash case "$ACTION" in add) mkdir -p /mnt/$DEVICE mount /dev/$DEVICE /mnt/$DEVICE ;; remove) umount /mnt/$DEVICE rmdir /mnt/$DEVICE ;; esac ``` 2. **自定义设备规则** 通过创建预执行脚本实现高级控制： ```bash # /etc/hotplug.d/iface/00-custom [ "$INTERFACE" = "wan" ] && { logger "WAN接口状态变更：$ACTION" } ``` #### 三、调试与验证 1. **事件触发测试** ```shell # 模拟存储设备插拔 echo add > /sys/block/sda/uevent ``` 2. **日志监控方法** ```shell logread -f | grep hotplug ``` #### 四、进阶配置建议 1. **冷插拔处理优化** 对于启动时已连接的设备，建议在/etc/rc.local添加初始化检测： ```bash for dev in $(ls /sys/block); do hotplug-call block $dev done ``` 2. **权限控制** 通过mdev规则实现细粒度权限管理： ```shell # /etc/mdev.conf sd[a-z][0-9] 0:0 660 */etc/hotplug.d/block/mount.sh ```
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值