Linux 内核中的 LZ4 实现正在迎来一次维护方式的调整。三星工程师 Michal Wilczynski 提交了一组包含 9 个 patch 的 RFC，目标是停止继续维护内核自己的 LZ4 分叉，改为直接引入上游 vendor 源码，并在构建阶段通过适配层满足内核接口和配置要求。
这不是一次单纯的代码搬家。它改变的是上游同步的责任边界：压缩算法代码尽量保持原样，内核特有的宏、类型、内存分配和构建逻辑集中到外围适配代码中。这样一来，下一次同步上游时，主要动作可以退化为复制目录、更新版本标记，再运行内核测试。
fork 的维护成本并不隐形
维护一份独立 fork，短期看似方便，长期却会持续产生同步成本。上游修复了边界条件、解压安全问题或性能回归后，内核维护者需要手工识别差异，再把补丁移植到已经改造过的代码上。
更麻烦的是，fork 往往会同时混入三类变化：
- 上游算法实现本身的变化；
- 内核为了适配旧接口而做的局部修改；
- 构建系统、配置选项和平台相关的兼容代码。
当这三类代码交织在同一个目录里，审查者很难判断一次更新到底引入了什么。同步失败也不一定会表现为编译错误，某些差异可能只在特定输入、特定架构或解压路径上暴露。
摘要提到，内核中的 LZ4 解压器最后一次跟随上游更新已经相隔较久。这正说明了 fork 模式的风险：代码虽然能工作，但与上游之间的距离会不断扩大，最终让一次普通升级变成高风险移植工程。
vendor 源码与适配层分开
RFC 的核心思路是把 LZ4 代码分成两个边界明确的区域：
vendor目录保存尽可能未经修改的上游源码；- 内核侧适配代码负责类型映射、配置开关、内存操作和导出接口。
这种布局的价值不在于目录名字，而在于限制修改范围。上游文件不应该为了适配内核而散落大量 #ifdef，内核自身的特殊需求也不应该直接改写算法实现。
可以把它理解成一个稳定的接口层。上游 LZ4 只需要遵守自己的源码和构建约定，内核则通过 wrapper 或配置文件把它接入现有的压缩 API。两边的变化都更容易被单独审查。
这类方案也有边界。并非所有第三方代码都能原样放入内核：许可证、编译器兼容性、禁用用户态依赖、整数类型和错误处理方式，都需要在引入前确认。因此，“原样同步”通常意味着尽量不修改 vendor 文件，而不是跳过集成审查。
一个可复用的同步流程
下面的示例是一个简化的工程流程。它假设已经把目标版本的上游 LZ4 源码放在 ../lz4-upstream，项目自身的适配层位于 lib/lz4。目录名和构建命令需要按实际项目调整。
#!/usr/bin/env bash
set -euo pipefail
UPSTREAM_DIR="${1:-../lz4-upstream}"
VENDOR_DIR="lib/lz4/vendor"
if [[ ! -d "$UPSTREAM_DIR" ]]; then
printf 'upstream directory not found: %s\n' "$UPSTREAM_DIR" >&2
exit 1
fi
mkdir -p "$VENDOR_DIR"
# 只替换 vendor 源码；适配层和项目构建文件保持在外部。
find "$VENDOR_DIR" -mindepth 1 -maxdepth 1 -exec rm -rf {} +
cp -a "$UPSTREAM_DIR"/. "$VENDOR_DIR"/
# 记录来源版本，便于审查和下次同步。
if [[ -f "$UPSTREAM_DIR/VERSION" ]]; then
cp "$UPSTREAM_DIR/VERSION" "$VENDOR_DIR/VERSION"
fi
git diff --stat -- "$VENDOR_DIR"
printf 'vendor refresh complete; review the diff before committing.\n'
实际项目中，还应把同步流程拆成几个可审查的步骤：
- 先确认上游版本、许可证和发布说明；
- 单独提交 vendor 文件更新；
- 单独提交适配层或构建系统改动；
- 在支持的架构上执行编译、压缩和解压测试；
- 对比同步前后的二进制大小、性能和错误处理行为。
如果项目使用 Git，也可以给 vendor 目录增加版本元数据，例如 UPSTREAM_COMMIT 文件。这样审查者无需猜测代码来自哪个上游快照，自动化脚本也能据此判断是否已经完成同步。
对内核维护的实际影响
这种重构不会自动消除所有升级风险，但会让风险更容易定位。算法更新、内核适配和构建变化被拆开之后，补丁审查可以回答更具体的问题：上游代码是否完整同步？适配层是否改变了语义？某个架构是否依赖了未公开的内部行为？
对压缩代码而言，测试范围尤其重要。至少应覆盖：
- 空输入、极短输入和高压缩比数据；
- 压缩后再解压的往返一致性；
- 截断数据、损坏数据和输出缓冲区不足；
- 32 位与 64 位平台的构建；
- 内核启动、文件系统或休眠恢复等真实调用路径。
另外，vendor 代码的“接近原样”不应被当成免审查的理由。上游项目和内核的编译选项、调用约定、错误模型可能不同，适配层必须明确记录这些差异。否则，目录看起来干净了，隐含的兼容性问题仍然存在。
这件事值得借鉴什么
Linux 内核这次 RFC 体现的是一种很实用的依赖管理原则：第三方实现越接近上游，升级越像同步依赖；本地差异越分散在算法代码中，升级越像重新维护一个项目。
如果你的项目也维护着一份长期未同步的压缩库、协议解析器或加密实现，可以用下面的清单评估是否适合类似重构：
- 能否把上游源码放入独立的 vendor 目录？
- 本地修改中，哪些属于真正必要的适配？
- 是否可以通过 wrapper、配置或构建参数替代直接改源码？
- 是否有自动化脚本记录上游版本并生成差异？
- 是否有覆盖损坏输入和多架构构建的测试？
最终目标不是追求“零修改”的形式，而是让每一处修改都有清晰归属：算法问题回到上游解决，内核集成问题留在适配层解决。对一个长期维护的底层组件来说，这通常比继续扩大 fork 更可控。