第四章：交换机软件架构——嵌入式Linux/RTOS下的分层设计
好，咱们今天聊聊交换机软件架构。说实话，很多刚入行的工程师觉得交换机就是个硬件盒子，插上电就能用。其实不然，真正让交换机“聪明”起来的，是藏在里面的软件系统。
我这些年调试过的车载交换机，从博通到Marvell，再到国产的盛科，软件架构虽然各有千秋，但核心思路都差不多。说白了，就是怎么把硬件能力通过软件暴露出来，让上层应用能方便地控制。
4.1 嵌入式Linux vs RTOS：怎么选？
先解决第一个问题：用Linux还是RTOS？
我个人习惯是这么判断的：
- 功能复杂度：如果只需要做简单的二层转发，RTOS完全够用。我早期做过一个项目，用FreeRTOS跑一个8口交换机，代码量不到2万行，稳得很。
- 协议栈需求：一旦涉及STP、RSTP、IGMP Snooping这些复杂协议，Linux的优势就出来了。你想想看，Linux内核里这些协议栈都是现成的，你只需要调API就行。
- 调试便利性：这一点我深有体会。Linux下有gdb、perf、tcpdump，出了问题能快速定位。RTOS下？嗯，串口打印加逻辑分析仪，有时候能把你逼疯。
我的建议：车载交换机现在越来越复杂，我个人倾向于用嵌入式Linux。除非你的MCU资源实在紧张（比如只有几百KB RAM），否则别跟自己过不去。
4.2 交换机驱动：硬件和软件的桥梁
驱动层，说白了就是让CPU能“听懂”交换芯片在说什么。这里有个关键点：交换芯片和普通网卡不一样。
普通网卡你配个MAC地址、IP地址就能跑。交换芯片呢？你得配置VLAN表、FDB表、ACL规则、端口属性...这些寄存器动辄几百个，手写？不现实。
我见过最典型的驱动分层是这样的：
+------------------+
| 用户态应用 | (brctl, iproute2, 自定义APP)
+------------------+
| SDK API层 | (芯片厂商提供)
+------------------+
| 内核驱动层 | (SPI/MDIO/RGMII接口)
+------------------+
| 交换芯片硬件 |
+------------------+这里有个坑，我曾经踩过：驱动层不能直接暴露所有寄存器给用户态。为什么？安全性和稳定性。你想想看，如果用户态程序不小心写错了某个关键寄存器，整个交换机可能就挂了。
避坑指南：我曾经在一个项目里，为了图方便，把芯片的全局控制寄存器直接mmap到了用户态。结果测试同事写了个死循环，不断复位芯片...嗯，那天的日志我现在还记得，全是“Link down - Link up”的告警。
4.3 SDK分层设计：厂商的“黑盒”与“白盒”
说到SDK，不同厂商的策略差别很大。
| 厂商 | SDK特点 | 我的评价 |
|---|---|---|
| Broadcom | SDK非常成熟，API封装很厚 | 好用但贵，文档有时候跟不上 |
| Marvell | 相对开放，寄存器级可操作 | 灵活，但需要你对芯片很了解 |
| 盛科 | 国产化，SDK正在完善中 | 支持好，但生态还在建设 |
我个人习惯是：不要完全依赖厂商SDK。为什么？因为SDK更新慢，而且有些bug你等不起。我一般会在SDK之上再封装一层自己的抽象层，这样换芯片时改动最小。
举个例子，配置VLAN：
// 厂商SDK的API
int bcm_vlan_create(int unit, int vid);
int bcm_vlan_port_add(int unit, int vid, int port);
// 我封装的抽象层
int switch_vlan_create(int vid);
int switch_vlan_add_port(int vid, int port, bool tagged);你看，多了一层封装，以后换芯片只需要改底层实现，上层应用完全不用动。
4.4 用户态与内核态交互：性能与安全的博弈
这个问题，说白了就是：配置走哪条路？
常见的交互方式有三种：
- ioctl：最传统的方式，适合低频配置。我早期项目都用这个，简单直接。
- netlink：Linux推荐的方式，支持异步通信。比如你要监听端口状态变化，用netlink最合适。
- sysfs：通过文件系统暴露属性。适合调试，但不适合生产环境（性能差）。
我的经验：对于车载交换机，我建议用netlink + ioctl的组合。netlink处理动态事件（比如链路变化），ioctl处理静态配置（比如VLAN划分）。这样既保证了实时性，又简化了代码。
这里有个细节要注意：内核态不能做阻塞操作。我见过有人在内核驱动里调用msleep()，结果整个网络栈都卡住了。嗯，这种bug查起来特别痛苦，因为问题复现概率还不高。
4.5 实战案例：一个VLAN配置的完整流程
好，咱们来个实际的。假设你要在车载交换机上创建一个VLAN 100，并把端口3和端口4加进去。
用户态程序会这样做：
// 1. 打开设备
int fd = open("/dev/switch0", O_RDWR);
// 2. 创建VLAN
struct switch_vlan_cfg cfg;
cfg.cmd = SWITCH_VLAN_CREATE;
cfg.vid = 100;
ioctl(fd, SWITCH_IOCTL_VLAN, &cfg);
// 3. 添加端口
cfg.cmd = SWITCH_VLAN_ADD_PORT;
cfg.port = 3;
cfg.tagged = 0; // untagged
ioctl(fd, SWITCH_IOCTL_VLAN, &cfg);
cfg.port = 4;
ioctl(fd, SWITCH_IOCTL_VLAN, &cfg);
// 4. 关闭设备
close(fd);内核驱动收到ioctl后，会调用SDK的API去配置芯片寄存器。整个过程看起来简单，但实际调试时你会发现：芯片的寄存器不是写进去就生效的。
我曾经遇到过一个情况：VLAN配置写进去了，但报文就是不通。查了两天，最后发现是芯片的VLAN学习功能没开。你想想看，这种问题靠看代码是看不出来的，必须用抓包工具或者芯片自带的debug功能。
4.6 总结一下
交换机软件架构，说白了就是三个层次：
- 驱动层：搞定硬件通信，别让上层操心寄存器细节
- SDK层：善用厂商提供的API，但别完全依赖
- 应用层：关注业务逻辑，通过netlink/ioctl与内核交互
最后说一句：调试能力比编码能力更重要。我见过太多人代码写得漂亮，但出了问题就抓瞎。记住，交换机是个实时系统，很多bug只有在特定流量模式下才会出现。多准备几套调试方案，总没错。
下一章咱们聊聊VLAN的实际配置，包括Access、Trunk、Hybrid这些端口模式的区别。到时候我会拿一个真实的车载网络拓扑来演示，敬请期待。