hotplug脚本调用

hotplug脚本调用

hotplug调用流程

最终调用hotplug脚本在netifd interface-event.c:

    char *eventnames[] = {
  "ifdown", "ifup", "ifupdate"};
    setenv("ACTION", eventnames[event], 1);
    setenv("INTERFACE", ifname, 1);
    if (device)
        setenv("DEVICE", device, 1);
    argv[0] = hotplug_cmd_path;
    argv[1] = "iface";
    argv[2] = NULL;
    execvp(argv[0], argv);
    exit(127);

netifd’s cycle appears to be:

1. Start some proto-specific mechanism for acquiring interface configuration. For DHCP this is driven by proto-shell.c, which spawns /lib/netifd/proto/dhcp.sh, which is a thin wrapper around udhcpc. udhcpc is long-lived and set up to call back into /lib/netifd/dhcp.script for dhcp events:
     833 root      1488 S    udhcpc -p /var/run/udhcpc-eth1.pid -s /lib/netifd/dhcp.script -f -t 0 -i eth1 -C
    

2. dhcp.script packages variables from udhcpc into json and end up doing ‘ubus call network.interface notify_proto ’. This in turn is handled by netifd in proto-shell.c, in proto_shell_notify. Action is 0, which leads into proto_shell_update_link.

3. proto_shell_update_link delivers an event to the interface through state->proto.proto_event (interface_proto_cb), which calls interface_event, which leads to the snippet above, calling into /sbin/hotplug-call with ACTION=ifupdate.

代码实现

内核

代码路径：linux/drivers/net/raeth/raether.c
内核，网口down/up 在raether.c中监测寄存器来判断网口的插拔，当出现WAN口插拔事件之后，向udhcpc发送信号release/renew

#if defined(CONFIG_RALINK_MT7621) || defined(CONFIG_ARCH_MT7623)
    fp = filp_open("/var/run/udhcpc-eth1.pid", O_RDONLY, 0);