3. VxWorks内核镜像裁剪
VxWorks 的镜像裁剪不是“把用不到的东西删掉”这么简单，它本质上是一次从产品需求反推系统能力边界的工程活动。裁剪的目标有三个：第一，镜像能启动并跑通产品必需功能；第二，镜像体积和内存占用满足 Flash、RAM 预算；第三，裁剪后的配置可复现、可回归、可交付。本节以“工业网关”这一典型产品为例，走完从需求到验证的完整闭环。
一、先明确裁剪的输入：产品需求清单
裁剪前必须先有一份可量化的需求清单，否则“最小”无从判断。假设某工业网关产品需求如下（示例参数，用于教学演示）：
| 需求项 | 具体要求 | 对内核配置的影响 |
|---|---|---|
| 网络功能 | 2 路以太网、静态路由、NAT | 需 INCLUDE_NETWORK、END、IPNET、NAT |
| 串口通信 | 4 路 RS485，Modbus RTU | 需串口驱动、tty 层 |
| 文件系统 | 只读根文件系统 + 少量配置写入 | ROMFS + dosFs 或 TFFS |
| 调试接口 | 量产版关闭 Shell，保留日志 | 去掉 INCLUDE_SHELL、INCLUDE_TARGET_SHELL |
| 资源预算 | 镜像 ≤ 2.5 MB，启动后 RAM ≤ 8 MB | 决定组件取舍的硬约束 |
这份清单是裁剪的“合同”。任何组件是否保留，都要能回答“它对应哪条需求”。没有需求支撑的组件，默认删除。
二、组件选择：从功能到组件的映射
VxWorks 的组件以 INCLUDE_ 宏的形式在 config.h / vxWorks.h 中体现。裁剪时按“功能域”分组决策，比逐个宏判断更可靠。典型分组如下：
- 内核基础：任务、信号量、消息队列、看门狗、内存管理。这些是绝大多数产品的必需项，一般保留。
- 网络协议栈：若产品无网络，可整体去掉
INCLUDE_NETWORK及其依赖，通常能省下 300～600 KB。 - 文件系统：只读场景用 ROMFS 即可；需要掉电保存配置才引入 dosFs/TFFS。
- 调试与诊断：Shell、符号表、错误打印在量产版应关闭，但建议保留一个轻量日志通道。
- 可选中间件：SNMP、Web、SSL 等按产品形态决定，网关类产品常保留 SNMP 精简版。
三、配置内核：关键宏与依赖关系
VxWorks 组件之间存在依赖，去掉底层组件会导致上层编译失败。例如 INCLUDE_IPNET 依赖 INCLUDE_NETWORK 和 INCLUDE_END；INCLUDE_NAT 又依赖 IPNET。因此配置时要按“自底向上”的顺序检查。下面是一段示例配置片段（教学用，非实测）：
/* 网络：保留以太网与 IP，去掉 IPv6 与冗余协议 */
#define INCLUDE_NETWORK
#define INCLUDE_END
#define INCLUDE_IPNET
#define INCLUDE_NAT
#undef INCLUDE_IPV6
#undef INCLUDE_TCP_DEBUG
/* 文件系统：只读根 + 配置分区 */
#define INCLUDE_ROMFS
#define INCLUDE_DOSFS
#undef INCLUDE_NFS
/* 调试：量产关闭 Shell，保留日志 */
#undef INCLUDE_SHELL
#undef INCLUDE_TARGET_SHELL
#define INCLUDE_LOGGING
配置完成后，用 make 或 Tornado/Workbench 的构建流程生成镜像。此时要关注两个产物：vxWorks（可加载镜像）和 vxWorks.bin（二进制烧录镜像）。前者用于调试，后者用于量产烧录。
四、生成最小可启动镜像并验证资源占用
镜像生成后，不能只看“能不能编译”，必须实际启动并测量。验证分三步：
- 启动验证：通过串口或网口加载镜像，确认内核启动、任务调度正常、网络接口 up、串口可收发。
- 体积验证：查看
vxWorks.bin大小，与预算对比。若超预算，优先检查是否误留了调试符号或未使用的协议栈。 - 内存验证：启动后通过
memShow或系统日志查看空闲内存、堆使用峰值，确认 RAM 占用在 8 MB 以内。
下面这张图展示了从需求到验证的完整裁剪链路，以及每一步的关键判断点：
五、常见问题与判断依据
裁剪过程中最容易踩的坑有三类。第一类是依赖断裂：去掉某个底层组件后，上层组件编译报错或启动时挂死。判断方法是看构建日志中的未定义符号，以及启动时的 undefined symbol 打印。第二类是体积反弹：明明删了组件，镜像却变大，通常是调试符号（-g）或未 strip 导致，检查编译选项即可。第三类是内存泄漏：裁剪后功能正常，但运行数小时后内存耗尽，这往往是因为去掉了某个组件的清理逻辑，需要结合 memShow 的多次采样判断趋势。
六、可交付的裁剪检查表
为了让裁剪结果可复现，建议每次裁剪后填写一份检查表。以下为示例结构，可直接用于项目记录：
| 检查项 | 判断标准 | 本次结果 |
|---|---|---|
| 镜像体积 | ≤ 2.5 MB | 2.31 MB |
| 启动后空闲 RAM | ≥ 8 MB 可用 | 8.6 MB |
| 网络功能 | ping / NAT 正常 | 通过 |
| 串口功能 | 4 路 RS485 收发正常 | 通过 |
| Shell 状态 | 已关闭 | 已关闭 |
| 日志通道 | 可输出到串口 | 正常 |
这张表的价值在于：它把“裁剪”从一次性的手工操作，变成了可对比、可回归的工程记录。下一次需求变更时，只需在表上增减行，就能快速判断影响范围。裁剪的终点不是“镜像变小”，而是“在满足产品需求的前提下，资源占用可控、配置可复现、问题可定位”。