Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Similar to Linux kernelのbspとupstream
Similar to Linux kernelのbspとupstream (20)
More from wata2ki
Recently uploaded
Recently uploaded (8)
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等で同一コンフィグ設定でテストする等