如何查看追踪Linux内核I2C子系统变更及相关技术问题咨询

作为常年跟内核子系统打交道的开发者，我能理解你在移植I2C变更时遇到的头疼问题——老内核和新内核的结构差异确实让人头大。针对你的三个问题，我给你具体的实操方向：

要追踪I2C子系统的演化，最直接的工具就是内核的Git仓库，这里有几个实用的方法：

• 按目录追踪变更：直接针对I2C驱动目录查看提交历史，命令是：

  git log --oneline --decorate drivers/i2c/
  

  这个命令会输出所有涉及drivers/i2c/目录的提交，简洁明了。如果想查看具体某段时间的变更，可以加上--since="2016-01-01" --until="2016-12-31"这样的时间范围。
• 查找特定补丁的状态：你提到的2016年的补丁，可以先提取补丁的Commit ID（如果被合并进主线的话，相关页面会显示对应的commit），然后用以下命令检查它是否存在于你的4.4.127内核树中：

  git log --grep="9395089" # 或者直接用commit ID
  git show <commit-id>
  

  如果找不到，说明这个补丁要么没被主线合并，要么被后续的提交修改/替换了。这时可以用git log --grep="i2c probe_new"来搜索相关功能的替代提交。
• 对比版本间的差异：如果想直接看4.4.127和主线内核的I2C子系统差异，可以用：

  git diff v4.4.127 mainline -- drivers/i2c/
  

• 查看维护者和讨论脉络：用内核自带的脚本找到I2C子系统的维护者，然后查看他们提交的补丁和相关讨论，命令是：

  scripts/get_maintainer.pl drivers/i2c/
  

内核版本迭代有它的规律，慢慢积累就能摸清楚：

• 先搞懂版本规则：区分主线（mainline）、稳定版（stable）、长期支持版（LTS）——比如4.4和4.9都是LTS版本，会接收bug修复和少量兼容的功能backport，但不会加入大规模的结构变更。
• 跟踪子系统的更新说明：每个内核版本的更新日志里，会专门提到子系统的变化。你可以重点看Documentation/Changes文件，或者每个版本发布时的官方公告，里面会有I2C子系统的改进说明。
• 订阅子系统邮件列表：加入linux-i2c@vger.kernel.org邮件列表，看开发者们讨论的问题、提交的补丁和设计思路，这是理解子系统演化最直接的方式。
• 对比不同LTS版本的差异：拿4.4、4.9、5.4这些LTS版本的I2C目录做对比，看哪些功能被backport了，哪些没有，理解内核团队对stable版本的更新策略——一般只有关键bug修复和兼容性补丁会被backport，大规模重构不会进入LTS。
• 从文档入手：内核的Documentation/i2c/目录下有详细的子系统说明，不同版本的文档变化也能反映功能的演进，比如新的of_*接口文档会告诉你它的设计目的和用法。

移植内核变更最怕上来就大动干戈，得一步步来：

• 先明确你的核心需求：不要想着把所有新变更都移植过来，先聚焦你需要的of_*支持和probe_new相关功能，把这些功能对应的提交从主线找出来，单独追踪。
• 做增量移植：
  1. 先从最基础的核心变更开始，比如i2c-core.c和i2c-core-of.c里的小补丁，先移植单个提交，解决编译冲突，测试通过后再移植下一个。
  2. 对比4.9 LTS版本的I2C代码——因为4.9和4.4同属旧LTS，结构差异比主线小很多，如果你的目标补丁在4.9里有backport版本，直接参考4.9的代码来修改4.4的，会省很多事。
• 测试是关键：每移植一个小模块，就编译内核，烧写到BeagleBone Black上测试I2C设备的功能，比如用i2cdetect工具检查设备，用应用程序测试读写，确保没有panic、死锁或者功能异常。
• 处理冲突的技巧：遇到代码冲突时，不要盲目修改，先看冲突部分的上下文，理解新代码的逻辑，再适配到旧版本的代码结构里。比如如果新代码用了一个旧版本没有的函数，要么自己实现这个函数的简化版，要么找替代方案。
• 求助社区：如果遇到卡壳的地方，把你的冲突代码、移植的目标提交和问题描述整理好，发到linux-i2c邮件列表里，维护者和其他开发者会给出针对性的建议——记得说明你是在4.4.127上移植，这样大家能给出更准确的方案。
• 维护移植补丁：把你做的每一次修改都做成单独的Git补丁，这样后续内核版本更新时，你可以轻松地重新应用这些补丁，也方便排查问题。

内容的提问来源于stack exchange，提问作者mrigendra