【问题标题】:How to migrate linux kernel to a higher kernel version如何将linux内核迁移到更高的内核版本
【发布时间】:2014-01-27 21:37:08
【问题描述】:

我正在开发一些 linux 内核模块,我当前的内核是 3.8,我想将它升级到内核 3.10

我想到了两种方法:

  1. 要么签出一个单独的3.10 分支,然后将它与我当前的3.8 分支合并。
  2. 或用3.9 补丁修补3.8,然后用3.10 修补它(kernel.org 上提供的补丁是当前版本和以前版本的差异,我相信)

我应该采用哪种方法?有没有更好的方法?

我使用 git 作为版本控制软件。

【问题讨论】:

  • AFAIK 为使您的模块工作,您也需要更换系统的内核,例如,如果您针对内核的 3.10 版本编译模块,那么您的系统也需要运行该版本。
  • 1) 找到最接近您的基础且有 3.10 可用的版本。 2)将您当前的树与该树的 3.8 进行比较。 3) 将您的更改应用到该版本的 3.10,在可能的情况下自动和手动包括在需要时移植到新机制的范围。 4) 恢复向前发展进度
  • rendon :是的,我正在替换整个内核。 @ChrisStratton:感谢您的建议,我正在做类似于您建议的事情,我已经下载了内核树,我已经确定了最接近我的基础的版本,它有 3.10 可用。然后我将采用原始 3.8 和 3.9 的差异,将其应用于我的 3.8,然后再次使用原始 3.9 和 3.10。希望它会起作用。
  • 与将您的私有版本与上游进行比较相比,这可能会是一个更大且信息量更少的差异。后者的一个附带好处是您会发现您需要的上游标准有哪些变化。

标签: linux git linux-kernel upgrade patch


【解决方案1】:

就 git 而言,您可以选择任何一种方式。

您可以获取 v3.8 源代码,创建一个单独的分支(例如,称为 my_modules),在该分支中应用您的更改,然后提交它们。然后你必须将该分支与实际的内核源代码合并(我建议使用上游master,但你可以选择内核开发历史中的任何其他点(提交)):git merge <chosen-branch-o-tag-o-commit>。此时您可能必须解决合并冲突(如果有),将您的模块更新为新的内核内部 API 等,然后提交合并状态。请参阅git merge --help 和其他相关的 git 文档。现在,您的更改已适应所选内核版本,并且可能会看到上游内核和修补内核之间的差异:git diff <chosen-branch-o-tag-o-commit> HEAD。生成的提交图片如下所示:


A -    ...   - B
 \             \
   D1 - D2... - M

其中 A 是初始分支点(3.8 内核),B 是您合并的提交(较新的内核),D1..DN 是您的驱动程序的提交,M 是合并。

或者,您也可以使用另一种称为变基的方法。在这种情况下,您将初始提交序列“移植”到新选择的根:git rebase -i B。然后 git 将尝试将整个序列 D1...DN 迭代地重新应用到新的根 B。请注意,在每个 步骤 1...N 中,您可能会遇到需要解决的冲突,然后使用 git rebase --continue 继续重新定位过程。在 [successful] 结束时,您将获得一个 new 提交序列 D'1 - D'N 从 B 增长:


A - ... - B
             \
              D'1 - .... D'N

请注意,从技术上讲,D'1...D'N 看起来/相似/与您原来的 D1...DN 是不同的。它们有自己的提交时间,补丁文本可能略有不同等。根据您的需要,它们可能是也可能不是您需要的。

【讨论】:

  • 感谢您的详细解答,经过这里的一些讨论和建议,我想我会采用 diff & patch 方法。
  • 事实上 diff & patch 方法很不方便。这就像用马和手犁耕种田地,而其他人都使用拖拉机和收割机。您将不得不为您希望将模块更新到的每个版本内核重复所有无聊的操作。但你当然可以决定。
  • 原来我的驱动程序在移植到更高版本的内核时变化很小。所以,对我来说最简单的事情就是创建一个补丁并应用到最新的内核版本。不过感谢您的洞察力!
猜你喜欢
  • 2023-03-27
  • 1970-01-01
  • 2018-09-17
  • 2012-02-16
  • 1970-01-01
  • 1970-01-01
  • 2018-04-17
  • 2019-09-26
  • 2014-11-28
相关资源
最近更新 更多