Use mdev to automatically generate the device node

本文介绍了一个典型的系统启动初始化脚本示例,展示了如何通过 rc.local 和 init.d/rcS 脚本来挂载 sys 和 proc 文件系统,配置 tmpfs 文件系统,并启动 mdev 服务来动态创建设备文件。

in the init script, e.g: rc.local

cat etc/init.d/rcS 
#!/bin/sh 
 
 
mount -o sys /sys 
mount -o proc /proc 
 
 
echo "----------mount /sys as sysfs" 
mount -t tmpfs mdev /dev 
echo "----------Starting mdev......" 
echo /sbin/mdev > /proc/sys/kernel/hotplug 
mdev -s


<think>我们正在处理网络设备数据包传递逻辑,特别是当ingress设备被绑定到L3主设备时,需要将skb传递给其处理程序进行处理。 根据引用[1]中的代码片段,我们看到在ip_rcv_finish函数中,首先调用了l3mdev_ip_rcv(skb)来处理这种情况。 函数l3mdev_ip_rcv的作用是:如果接收数据包的设备(ingress设备)被绑定到一个L3主设备(例如VRF设备),那么数据包将被传递给该L3主设备的处理函数。 这样做的目的是为了让L3主设备有机会处理数据包,例如在VRF(Virtual Routing and Forwarding)环境中,数据包需要根据VRF实例进行路由。 具体来说,l3mdev_ip_rcv函数会检查接收数据包的网络设备是否是一个从设备(slave),并且它是否属于一个L3主设备(master)。如果是,那么它会将skb的输入设备(skb->dev)切换到L3主设备,并返回处理后的skb(可能被L3主设备处理修改过)。如果不需要处理,则返回原skb。如果处理过程中数据包被丢弃,则返回NULL。 在代码中,调用l3mdev_ip_rcv后,会检查返回的skb是否为NULL,如果是则直接返回NET_RX_SUCCESS(实际上这里可能是丢弃,但返回成功是为了避免重复处理错误?需要看内核具体实现,但通常返回NULL表示数据包已被处理或丢弃,无需继续)。否则,继续后续处理。 类似地,在发送路径上(引用[2]中的__ip_local_out函数),也有一个l3mdev_ip_out的调用,用于处理发送时设备被绑定到L3主设备的情况。 因此,用户的问题“if ingress device is enslaved to an L3 master device pass the skb to its handler for processing”正是由l3mdev_ip_rcv函数完成的。 总结: 在接收路径中,当数据包进入协议栈(ip_rcv)后,会调用ip_rcv_finish,而在ip_rcv_finish中首先会处理L3主设备的情况。这是为了支持像VRF这样的功能,使得网络栈能够根据不同的虚拟路由实例处理数据包。 注意:L3主设备(L3 master device)是Linux内核中用于实现三层虚拟化的一个概念,例如VRF设备。它允许在同一台主机上存在多个独立的路由表。 因此,处理逻辑如下: 1. 在接收路径:ip_rcv -> ip_rcv_finish -> l3mdev_ip_rcv 2. 在发送路径:__ip_local_out -> l3mdev_ip_out 这两个函数都是L3主设备框架的一部分,用于在数据包接收和发送时切换设备上下文。 如果用户想深入了解,可以查看Linux内核源码中关于l3mdev(Layer 3 master device)的实现。</think>### Linux网络设备数据包传递逻辑分析 在Linux网络协议栈中,当数据包进入网络设备时,系统会检查该设备是否被绑定到L3主设备(如VRF实例)。核心处理逻辑如下: 1. **入口处理函数调用链**: ```c ip_rcv() → ip_rcv_finish() → l3mdev_ip_rcv() ``` 2. **关键处理函数逻辑**: ```c /* net/ipv4/ip_input.c */ static int ip_rcv_finish(struct net *net, struct sock *sk, struct sk_buff *skb) { skb = l3mdev_ip_rcv(skb); // L3主设备处理入口 if (!skb) return NET_RX_SUCCESS; // 数据包已被处理或丢弃 ... } ``` 3. **l3mdev_ip_rcv() 核心逻辑**: - 检查接收设备(`skb->dev`)是否绑定到L3主设备 - 若设备被绑定: * 将数据包重定向到L3主设备的接收处理程序 * 更新数据包关联的网络命名空间 * 可能修改数据包的路由路径 - 返回处理后的新`skb`或`NULL`(若数据包被丢弃) 4. **L3主设备处理场景**: - **VRF(虚拟路由转发)**:实现多路由表隔离 - **容器网络**:为容器提供独立网络栈 - **SDN场景**:控制器管理的虚拟网络设备 5. **对称出口处理**: 在发送路径中同样存在对称逻辑: ```c __ip_local_out() → l3mdev_ip_out() // 发送路径的L3主设备处理[^2] ``` ### 实现原理详解 当网络设备被"enslaved"(绑定)到L3主设备时: 1. **设备关联**:通过`netdev_master_upper_dev_link()`建立绑定关系 2. **数据包重定向**:`l3mdev_ip_rcv()`调用`l3mdev_l3_rcv()`进行实际处理: ```c /* net/l3mdev/l3mdev.c */ struct sk_buff *l3mdev_ip_rcv(struct sk_buff *skb) { struct net_device *master = netdev_master_upper_dev_get_rcu(skb->dev); return (master && master->l3mdev_ops->l3mdev_l3_rcv) ? master->l3mdev_ops->l3mdev_l3_rcv(master, skb) : skb; } ``` 3. **路由决策**:重定向后的数据包会使用主设备的路由表进行转发决策 ### 实际应用场景 1. **VRF实现**: ```bash # 创建VRF设备 ip link add vrf-blue type vrf table 10 # 绑定物理设备到VRF ip link set eth0 master vrf-blue ``` 绑定后,所有`eth0`接收的数据包都会通过`vrf-blue`的路由表处理。 2. **容器网络隔离**:Docker/veth对通过此机制实现网络命名空间隔离。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值