![ パッチの比較をどのように行うか
◦ パッチの数は、MPが5201パッチ、UPが210パッチ、LPが2497パッチあるため、目視比較は難しい
◦ BSPカーネルから抽出したパッチMP(1)と、LTSIカーネルから抽出した同じパッチLP(1)の内容に差分
が出る
Fromに書かれているハッシュが変わってしまっている。LTSIカーネルは、linux-stableにLTSIパッチをgit applyで当
てるため変わってしまうと考えられる。
Subjectも抽出するパッチ数に連動して変わってしまう。format-patchのオプションで消せなくはないが、今度は順番
がわからなくなってしまうため、消すに消せない。
◦ 先頭から4行を比較対象から除外することで、パッチ本体のみの比較を行う(pythonを使用)
From 3b25797bc5edbf30e096aa45a8543c1f12128283 Mon Sep 17
00:00:00 2001
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date: Sun, 12 Feb 2012 23:09:28 -0800
Subject: [PATCH 0001/5201] LTSI Makefile addition
Change the extra version to have -ltsi to have a chance to
realize what
kernel version we are using.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Makefile b/Makefile
index addf1b0..5738a9b 100644
--- a/Makefile
From 1f71f3bbdeb3a4ebdca89858ae35b6fded47fea9 Mon Sep 17
00:00:00 2001
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date: Sun, 12 Feb 2012 23:09:28 -0800
Subject: [PATCH 0001/2497] LTSI Makefile addition
Change the extra version to have -ltsi to have a chance to
realize what
kernel version we are using.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Makefile b/Makefile
index addf1b0..5738a9b 100644
--- a/Makefile
BSPカーネルから抽出したパッチ LTSIカーネルから抽出したパッチ](https://image.slidesharecdn.com/linuxkernelbspupstream-161008130126/85/Linux-kernel-bsp-upstream-15-320.jpg)
![ Pythonによる機械比較によるBP抽出
◦ MP5201パッチのうち2637パッチの除外に成功
目標値は2497+210=2707パッチなので、97.4%
◦ 除外に失敗したパッチの分析
先頭4行を除くと、パッチ内のindex行に差が出てしまっており、同一のパッチと判断できなかった
UPが210パッチと少なかったため、subject行の改行が異なる位置で入ってしまい、5行目が不一致
になってしまった
残りの70パッチに関しては目視チェックにより除外できた
diff --git a/sound/soc/soc-jack.c b/sound/soc/soc-jack.c
index 0bb5ccc..7aa26b5 100644
--- a/sound/soc/soc-jack.c
diff --git a/sound/soc/soc-jack.c b/sound/soc/soc-jack.c
index 0bb5cccd..7aa26b5 100644
--- a/sound/soc/soc-jack.c
Date: Fri, 15 Nov 2013 14:53:14 -0800
Subject: [PATCH 2531/5201] usb: xhci: Check for XHCI_PLAT in
xhci_cleanup_msix()
Date: Fri, 15 Nov 2013 14:53:14 -0800
Subject: [PATCH 018/210] usb: xhci: Check for XHCI_PLAT in xhci_cleanup_msix()
勉強会でIndex行の差は、そのパッチの前に当たっているパッ
チに依存しているとのコメントをいただきました。
Index行はdiffから外してしまってよいようです。](https://image.slidesharecdn.com/linuxkernelbspupstream-161008130126/85/Linux-kernel-bsp-upstream-16-320.jpg)
Linux kernelのbspとupstream
- 1. wata2ki
- 2. 名前: wata2ki (watatuki) ◦ 元はハードウェアで画像処理をやっていましたが、現在は組 み込み屋をやっています 画像処理をやっていた当時は、ニューラルネットワークが画像処理で実用 化できるような形で使われるなんて予想していませんでした。。。 ◦ 最近はJetson-TK1/TX1向けのアンオフィシャルYocto BSPを 作り、そのうえでディスクトップ環境や別ボード向けのディスト ロを動かして遊んでいます ◦ GitHub https://github.com/watatuki
- 3. 今日は、Renesas社のPorterボードのBSPについてくるカーネ ルのバージョンアップに挑戦した時の内容について発表しま す Porter Board : R-Car M2 SoC ・ ARM®Cortex-A15 Dual Core 1.5GHz ・ PowerVR SGX544MP2 (3D) ・ 2 GB DDR3 memory (dual channel) Debug Ethernet (100 Mbps) Storage connection ・ one SATA rev. 3.1 port ・ one SD card slot ・ one microSD card slot Etc…
- 4. 背景 ◦ ARMのボードコンピュータでLinuxを動かす場合、Linuxのカーネルは、ベ ンダーのBSPとupstreamカーネルのどちらかを使うことになる BSPカーネル そのボード(SoC)のほぼ全ての機能を使うことができるが、特定のバージョン のカーネルにボード用の修正を加えたものなので、Linuxカーネルのバージョ ンアップに追従してくれない Renesas社のPorterボードの場合は3.10.31LTSI Nvidia社のJetson TK1ボードの場合は、3.10.40 Upstreamカーネル Linuxのメインラインそのものなので、カーネルの修正・改良はすべて入って いるが、使える機能が制限される ほとんどの場合GPUは使えない(Nvidiaは頑張れば3D描画くらいはできる) カーネルにドライバが入っていても、動くかどうかわからない/動かし方がわから ない ◦ つまり、どちらも最良の選択肢にはなりえない
- 5. 目的 ◦ 現状分析から、ARMのボードコンピュータでLinuxを動かす場合の目 指す姿は2種類 BSPカーネルのマイナーバージョンを最新まで上げて使う 最新機能は取り込めないが、バグフィクスは最新まで取り込める マイナバージョンアップなのでカーネルのソースが大きく変わることはなく、バッチ を当てやすい UpstreamカーネルにBSPカーネルの修正を適用して使う 最新機能もバグフィックスも取り込める BSPカーネルとのバージョン差が増えれば増えるほど、カーネルのソースが変 わってしまい、パッチを当てるのが難しくなる ◦ Upstreamカーネルを使う方法は、バージョン間の変更を理解してパッ チを当てないといけないため、職人芸になってしまう ◦ 今回は、職人芸要素の低いマイナーバージョンアップに取り組む
- 6. BSPのKernelバージョンは3.10.31-LTSI ◦ 3.10.xはLTSに選ばれており、サポートが長いことで有名なREL7に採 用されていることから、他のバージョンよりも長期間のメンテナンスが 期待できる 次のLTSに選ばれた3.14は2016/9/11にEOLになってしまったが、 3.10は2016/10/2現在メンテナンスが続いている ◦ 3.10.xの最新バージョンは3.10.103(2016/8/28時点) BSPは3.10.31-LTSIから分岐しており、それ以降のメンテナンスパッ チが当たっていない 当たっていないパッチの数は3536ある ARM固有のパッチはBSPに取り込まれているケースもあるが、共通部は 手薄 ext4のFixと予想されるパッチだけでも53個ある 注. REL: Red Hat Enterprise Linux
- 7. LTSIって何？？ ◦ Linux Foundationのプロジェクト ◦ LTSをベースにして、さらなる長期サポートと機能追加パッチ のバックポートを行う ◦ 1年につき1バージョンをLTSIに選定し2年間のサポートを行う これまでにLTSIになったのは、3.0-LTSI, 3.4-LTSI, 3.10-LTSI, 3.14-LTSI, 4.1-LTSI ◦ 興味をもったらここを参照 http://ltsi.linuxfoundation.org/
- 8. BSPカーネルを構成するパッチは3種類に分類できる ◦ LTSメンテナンスパッチ Kernel.orgで行われた3.10.xのマイナーバージョンアップで当てられ たパッチ 現在のカーネルは、3.10から3.10.31までが当たっている状態 ◦ LTSIパッチ L.F.のLTSI開発で当たったパッチ 現在のカーネルは、3.10.31-LTSIのパッチが当たっている状態 ◦ BSPパッチ UpstreamやLTSIに含まれていない、そのボード用のパッチ 何が当たっているのかわからない これらの整合をとって、3.10.103までのパッチを当てる必 要がある
- 9. BSPカーネルに3.10.32から3.10.103までのパッチを単純に当 てていく ◦ 手順 1. Kernel.orgにあるlinux-stableの3.10.yブランチをチェックアウト 2. git format-patchを使って3.10.31のバージョン付与以降のパッチを抽出 3. git amで抽出したパッチを当てる Upstream 3.10.31 3.10.32 patch 3.10.33～ 3.10.103 patch BSP patch Upstream 3.10.31 linux-stable LTSI(3.10.31) patch BSP KernelUpdate kernel BSP patch Upstream 3.10.31 LTSI(3.10.31) patch 3.10.32 patch 3.10.33～ 3.10.103 patch BSPから持ってくる メンテナンスパッチを持ってくる
- 10. パッチのコンフリクトが多発し、パッチ当てに失敗 ◦ LTSIパッチとメンテナンスパッチが衝突 LTSIパッチは3.11以降のカーネルからの新機能バックポートを含んでいる バックポートによる進化とメンテナンスによるBugFixが同じソースに対する 異なる変更を引き起こしてしまう 実際には必要としないAMD K6用のメンテナンスパッチが、LTSIとバッティング BeyTrail（Ｉｎｔｅｌ ATOM)のバックポート(LTSI)と、UARTのメンテナンスパッチが同 一ソースを別方向に変更しており、パッチのマージが困難 ◦ BSPパッチに含まれるARM固有部のBugFixの衝突 BSPとして必要と判断された、コアのワークアラウンドやARM固有部の BugFixがバックポートされているため、メンテナンスパッチでバックポートさ れたパッチが当たらない このパターンは、git am -3 を使うことである程度自動検出が可能 自動検出できない場合でも、修正対象ファイルのgit logをパッチのsubjectで検索 すると、同じ内容のパッチが当たっていることを見つけることができる
- 11. BSPカーネルから、BSP変更部分を抽出し、最新のLTSIに マージする ◦ 手順 1. BSPカーネルからBSPの変更を抽出してパッチを作る 2. 最新のLTSIカーネル(3.10.102-ltsi)を作成 3. git amで抽出したBSPのパッチを当てる Upstream 3.10.31 3.10.32～ 3.10.102 patch BSP patch Upstream 3.10.31 linux-stable+LTSI LTSI(3.10.31) patch BSP KernelUpdate kernel Upstream 3.10.31 BSPから持ってくる最新のLTSIから持ってくる LTSI(3.10.102) patch 3.10.32～ 3.10.102 patch LTSI(3.10.102) patch BSP patch
- 12. 苦労はあったが、パッチ当てに成功 ◦ 方針1で多発したパッチの衝突はほとんど発生しなかった 3.10.102 LTSIを起点としているため、方針1で問題となったバックポートによ る進化とメンテナンスによるBugFixの衝突は解決済み BSPパッチと3.10.102 LTSIとの衝突は方針1と同様に発生したが、ごく少数 で済んだ ◦ 方針2はBSPパッチの抽出が課題 コミットログからはBSPパッチとそれ以外の分別が困難 LTSIにもR-Carのパッチが含まれているため、パッチが当たるファイルでの分別が できない コミットログの内容や、Autherで判断できないか調査したが、結局できなかった BSPパッチを抽出するために、ブランチの起点を軸としたパッチの総当たり 検索でBSPの抽出を行った
- 13. BSPはLTSIから作られているため、LTSIの分岐点以降のパッチをチェックの対象にす る ◦ LTSIで一番最初に当たるのは MakefileにあるEXTRAVERSIONに-ltsiを設定するパッチなの で、このパッチを探す 調査の結果BSPはLTSI3.10.28でforkし、LTSI3.10.31相当になるようパッチがマージされていることが判 明 BSPパッチとマージしたパッチは順番に並んでいないため、分別の必要がある Upstream 3.10.28 Upstream 3.10.31 BSP 3.10.31 branch LTSI 3.10.28 LTSI 3.10.31 branch branch Upstream3.10.29～31のパッチと、 LTSIのパッチをBSPのブランチ にマージ LTSI 3.10.31相当のカーネルに BSP固有のパッチが入っている 状態
- 14. パッチを抽出するために、以下の仮説を立てた ◦ BSPパッチ抽出(1)で抽出したパッチの集合はMP ◦ 抽出したいBSP固有のパッチの集合はBP ◦ Upstreamの3.10.29～3.10.31のパッチの集合はUP ◦ Upstream3.10.31に対してLTSI 3.10.31で追加されたパッチの集合はLP ◦ MP(n)に対してUP,LPとのdiffをとり、一致するものを除外した結果はBPに等しい、すなわちUP∪LP ∪BP=MPである Upstream 3.10.28 Upstream 3.10.31 BSP 3.10.31 branch LTSI 3.10.28 LTSI 3.10.31 branch branch MP UP LP BP UP∪LP
- 15. パッチの比較をどのように行うか ◦ パッチの数は、MPが5201パッチ、UPが210パッチ、LPが2497パッチあるため、目視比較は難しい ◦ BSPカーネルから抽出したパッチMP(1)と、LTSIカーネルから抽出した同じパッチLP(1)の内容に差分 が出る Fromに書かれているハッシュが変わってしまっている。LTSIカーネルは、linux-stableにLTSIパッチをgit applyで当 てるため変わってしまうと考えられる。 Subjectも抽出するパッチ数に連動して変わってしまう。format-patchのオプションで消せなくはないが、今度は順番 がわからなくなってしまうため、消すに消せない。 ◦ 先頭から4行を比較対象から除外することで、パッチ本体のみの比較を行う(pythonを使用) From 3b25797bc5edbf30e096aa45a8543c1f12128283 Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Date: Sun, 12 Feb 2012 23:09:28 -0800 Subject: [PATCH 0001/5201] LTSI Makefile addition Change the extra version to have -ltsi to have a chance to realize what kernel version we are using. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> --- Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Makefile b/Makefile index addf1b0..5738a9b 100644 --- a/Makefile From 1f71f3bbdeb3a4ebdca89858ae35b6fded47fea9 Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Date: Sun, 12 Feb 2012 23:09:28 -0800 Subject: [PATCH 0001/2497] LTSI Makefile addition Change the extra version to have -ltsi to have a chance to realize what kernel version we are using. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> --- Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Makefile b/Makefile index addf1b0..5738a9b 100644 --- a/Makefile BSPカーネルから抽出したパッチ LTSIカーネルから抽出したパッチ
- 16. Pythonによる機械比較によるBP抽出 ◦ MP5201パッチのうち2637パッチの除外に成功 目標値は2497+210=2707パッチなので、97.4% ◦ 除外に失敗したパッチの分析 先頭4行を除くと、パッチ内のindex行に差が出てしまっており、同一のパッチと判断できなかった UPが210パッチと少なかったため、subject行の改行が異なる位置で入ってしまい、5行目が不一致 になってしまった 残りの70パッチに関しては目視チェックにより除外できた diff --git a/sound/soc/soc-jack.c b/sound/soc/soc-jack.c index 0bb5ccc..7aa26b5 100644 --- a/sound/soc/soc-jack.c diff --git a/sound/soc/soc-jack.c b/sound/soc/soc-jack.c index 0bb5cccd..7aa26b5 100644 --- a/sound/soc/soc-jack.c Date: Fri, 15 Nov 2013 14:53:14 -0800 Subject: [PATCH 2531/5201] usb: xhci: Check for XHCI_PLAT in xhci_cleanup_msix() Date: Fri, 15 Nov 2013 14:53:14 -0800 Subject: [PATCH 018/210] usb: xhci: Check for XHCI_PLAT in xhci_cleanup_msix() 勉強会でIndex行の差は、そのパッチの前に当たっているパッ チに依存しているとのコメントをいただきました。 Index行はdiffから外してしまってよいようです。
- 17. 最新のLTSI(3.10.102LTSI)に対してBSPパッチBPを適用する ◦ Linux-stable3.10.102に対して3.10.102用のLTSIパッチを適用し、3.10.102LTSIを作成 ◦ 3.10.102LTSIに対して、抽出したBPを当てることで、3.10.31から3.10.102までのメンテナ ンスを取り込んだBSPカーネルを作成する Upstream 3.10.102 Upstream 3.10.103 BSP 3.10.102 branch LTSI 3.10.102 branch BP BSP 3.10.31 この間の差は、カーネル のメンテナンスパッチの みになる この差の取り込みに関し ては、今後の課題
- 18. 目標とした3.10.102LTSIベースのBSPカーネル作成は成功 失敗と課題 ◦ LTSIパッチの抽出を誤って3.10.31ではなく3.10.28で行ってしまったため、その 間に追加された10パッチが最初にコンフリクトしてしまった 目視抽出で除外して対応 ◦ 抽出したBSPカーネルに、3.10.31以降に追加された一部のパッチが取り込ま れていたため、そのパッチがコンフリクト(49パッチ) これも数が少なかったため、gitのログと照合して3.10.102LTSI時点で当たっているも のを除外 ◦ PorterボードはBSPカーネルにYoctoのレシピでパッチを当てて対応していたた め、これを当てないと動作しなかった 不足しているパッチを適用して対応 ◦ どうしても当たらないパッチが一つだけ残ってしまった 変更行が衝突しており、有効な解決策がなく保留
- 19. 今回のまとめ ◦ 今回はRenesas社のPorterボード用BSPカーネルを題材として、Upstreamカーネ ルのメンテナンスを取り込む簡単な方法を検討、試験した。 ◦ ファイルサーチとdiffライブラリのあるpython使うことで、97%のパッチを機械的 に分別でき、手作業による分別を3%未満に抑えることができた。 今回の失敗をフィードバックすることで99%のパッチを機械的に分別できる見込み 残課題 ◦ LTSのメンテナンスに対して遅れがちなLTSIカーネルの最新版へのアップデー トには成功したが、LTSの最新には到達できていない(3.10.102~3.10.103の パッチを取り込めていない）ため、これに対する方策が必要 単純にパッチを当てれば済む可能性もあるが、現時点では未実施 試しにやったらあっさり当たってしまいました。現状3.10.104までのパッチを当てることに成功し ています。 ◦ 変更前後のリグレッションテストの方法が確立できていない LTP等で同一コンフィグ設定でテストする等