Androidカーネルを最新のLinuxStableに更新する方法

「カスタムカーネルの構築方法」や「Androidに最適なカスタムカーネル」などのAndroidカーネルに関するガイドを取り上げましたが、本日は、最新のLinux安定版に対してカーネルをアップストリームする方法を紹介します。

これは高度であることをご承知おきください もの–これまでカーネルをコンパイルしたことがない場合は、上記の「カスタムカーネルを構築する方法」ガイドに従う必要があります。このガイドでは、最新のLinux安定カーネルからのコミットを選択してAndroidカーネルにマージします。コンパイルする前に。

Androidカーネルを最新のLinux安定版にアップストリームすることには、最新のセキュリティコミットやバグ修正を最新のものにするなど、多くのプラスのメリットがあります。このガイドの後半で、いくつかの長所と短所について説明します。

>

Linux-Stableカーネルとは何ですか？

Linux-stableは、その名前が示すように、Linuxカーネルの安定したアームです。もう一方のアームは「メインライン」と呼ばれ、マスターブランチです。 。 Linuxカーネルの開発はすべてメインラインで行われ、通常は次のプロセスに従います。

1. Linus Torvaldsは、メンテナから2週間にわたって多数のパッチを受け取ります。
2. この2週間後、彼はrc1（4.14-rc1など）カーネルをリリースします。
3. 次の6〜8週間の毎週、バグとリグレッションの修正のみを含む別のRC（4.14-rc2、4.14-rc3など）カーネルをリリースします。
4. 安定していると見なされると、orgでダウンロードできるtarballとしてリリースされます（例：4.14）。

LTSカーネルとは何ですか？

毎年、グレッグは1つのカーネルを選び、それを2年間（LTS）または6年間（拡張LTS）維持します。これらは、安定性が必要な製品（Androidフォンやその他のIOTデバイスなど）を持つように設計されています。プロセスは上記とまったく同じですが、より長い時間発生します。現在、6つのLTSカーネルがあります（kernel.orgリリースページでいつでも表示できます） ）：

• 4.14（LTS） 、GregKroah-Hartmanによって管理されています
• 4.9（LTS） 、GregKroah-Hartmanによって管理されています
• 4.4（eLTS） 、GregKroah-Hartmanによって管理されています
• 4.1（LTS） 、SashaLevinによって管理されています
• 3.16（LTS） 、BenHutchingsによって管理されています
• 3.2（LTS） 、BenHutchingsによって管理されています

AndroidカーネルをLinuxStableにアップストリームする利点は何ですか？

重要な脆弱性が開示/修正された場合、安定したカーネルが最初にそれらを取得します。したがって、Androidカーネルは、攻撃、セキュリティ上の欠陥、および一般的なバグに対してはるかに安全になります。

Linux安定版には、Androidデバイスが使用しない多くのドライバーの修正が含まれていますが、これはほとんど不要ではありませんか？

「ほとんど」をどのように定義するかに応じて、はい、いいえ。 Linuxカーネルには、Androidシステムで使用されない多くのコードが含まれている可能性がありますが、新しいバージョンをマージするときにこれらのファイルとの競合が発生しないことを保証するものではありません。事実上誰もいないことを理解する UbuntuやMintのような最も一般的なLinuxディストリビューションでさえも、カーネルのすべての部分をビルドします。これは、あるので、これらの修正を行うべきではないという意味ではありません。 行うドライバーの修正 走る。たとえば、最も一般的なAndroidアーキテクチャとファイルシステムであるarm/arm64とext4を取り上げます。 4.4では、4.4.78（最新のOreo CAFタグのバージョン）から4.4.121（最新のアップストリームタグ）まで、これらのシステムのコミットの数値は次のとおりです。

nathan@flashbox ~/kernels/linux-stable (master) $ git log --format=%h v4.4.78..v4.4.121 | wc -l2285 nathan@flashbox ~/kernels/linux-stable (master) $ git log --format=%h v4.4.78..v4.4.121 arch/arm | wc -l58 nathan@flashbox ~/kernels/linux-stable (master) $ git log --format=%h v4.4.78..v4.4.121 arch/arm64 | wc -l22 nathan@flashbox ~/kernels/linux-stable (master) $ git log --format=%h v4.4.78..v4.4.121 fs/ext4 | wc -l18

最も時間のかかる部分は、最初の起動です。完全に最新の状態になったら、新しいリリースにマージするのにまったく時間がかかりません。新しいリリースには通常、100を超えるコミットが含まれていません。ただし、これによってもたらされる利点（ユーザーの安定性とセキュリティの向上）には、このプロセスが必要になります。

Linuxの安定したカーネルをAndroidのカーネルにマージする方法

まず、Androidデバイスが実行しているカーネルバージョンを把握する必要があります。

これは些細なことのように思えますが、どこから始めればよいかを知る必要があります。カーネルツリーで次のコマンドを実行します。

make kernelversion

現在のバージョンに戻ります。最初の2つの数字は、必要なブランチを把握するために使用され（たとえば、4.4カーネルの場合はlinux-4.4.y）、最後の数字は、マージを開始する必要があるバージョンを決定するために使用されます（たとえば、4.4を使用している場合）。 .21、次に4.4.22をマージします。

kernel.orgから最新のカーネルソースを入手します

kernel.orgは、最新のカーネルソースをlinux-stableリポジトリに格納しています。そのページの下部に、3つのフェッチリンクがあります。私の経験では、Googleのミラーが最速になる傾向がありますが、結果は異なる場合があります。次のコマンドを実行します：

git remote add linux-stable https://kernel.googlesource.com/pub/scm/linux/kernel/git/stable/linux-stable.gitgit fetch linux-stable

カーネル全体をマージするか、コミットを選択するかを決定します

次に、コミットをマージするか、チェリーピックをマージするかを選択する必要があります。それぞれの長所と短所、およびそれらを実行したい場合は次のとおりです。

注： カーネルソースがtarballの形式である場合は、チェリーピックが必要になる可能性があります。そうしないと、GitがOEMやCAFの変更ではなく、純粋にアップストリームに基づいて履歴を生成するため、何千ものファイルの競合が発生します。手順4に進んでください。

さくらんぼ狩り：

長所：

• どの競合が問題を引き起こしているのかを正確に把握しているため、競合の解決が容易になります。
• 各コミットは独自のものであるため、リベースが簡単です。
• 問題が発生した場合に二分するのが簡単

短所：

• 各コミットを個別に選択する必要があるため、時間がかかります。
• コミットが一見上流からのものであるかどうかを判断するのは少し難しいです

マージ

長所 ：

• すべてのクリーンなパッチがマージされるのを待つ必要がないため、高速です。
• あなたはコミッターではなく、アップストリームのメンテナーになるので、コミットがアップストリームからのものであるかどうかを確認するのは簡単です。

短所：

• 競合の解決は、git log / git blameを使用して競合の原因となっているコミットを調べる必要があるため、少し難しい場合があります。直接はわかりません。
• マージをリベースできないため、リベースは困難です。すべてのコミットを個別に選択することができます。ただし、頻繁にリベースするのではなく、可能な場合はgitrevertとgitmergeを使用してください。

最初に問題の競合を把握するためにチェリーピックを実行し、マージを実行してから、問題のコミットを元に戻して更新を容易にすることをお勧めします（最新の状態にするとマージが高速になるため）。

コミットをソースに一度に1バージョンずつ追加します

このプロセスの最も重要な部分は、一度に1つのバージョンです。アップストリームシリーズに問題のあるパッチがある可能性があります。これにより、起動に問題が発生したり、音や充電などが壊れたりする可能性があります（ヒントとコツのセクションで説明されています）。このため、バージョンを段階的に変更することが重要です。一部のバージョンでは、2000コミット以上よりも、50コミットで問題を見つける方が簡単です。問題のコミットと競合の解決をすべて理解した後でのみ、完全なマージを実行することをお勧めします。

さくらんぼ狩り

フォーマット：

git cherry-pick <previous_tag>..<next_tag>

例：

git Cherry-pick v3.10.73..v3.10.74

マージ

フォーマット：

git merge <next_tag>

例：

git merge v3.10.74

＃マーカーを削除して、マージコミットの競合を追跡することをお勧めします。

競合を解決する方法

C言語に関する十分な知識が必要なため、すべての競合を解決するためのステップバイステップのガイドを提供することはできませんが、ここにいくつかのヒントがあります。

マージする場合は、どのコミットが競合を引き起こしているのかを把握してください。これは、次の2つの方法のいずれかで実行できます。

1. git log -p v $（make kernelversion）.. を使用して、現在のバージョンとアップストリームからの最新バージョンの間の変更を取得します。 -pフラグを使用すると、各コミットによって行われた変更が表示されるため、確認できます。
2. ファイルに対してgitblameを実行して、その領域の各コミットのハッシュを取得します。次に、git show –format =fullerを実行して、コミッターがメインライン/安定版、Google、またはCodeAuroraのいずれからのものであるかを確認できます。

• すでにコミットがあるかどうかを確認します。 GoogleやCAFなどの一部のベンダーは、Dirty COW修正などの重大なバグをアップストリームで探しようとし、バックポートがアップストリームと競合する可能性があります。 git log –grep =” ”を実行して、何かが返されるかどうかを確認できます。含まれている場合は、コミットをスキップするか（git reset –hard &&git Cherry-pick –continueを使用してチェリーピッキングする場合）、競合を無視する（<<<<<<と======の間のすべてを削除する）ことができます。および>>>>>>）。
• 解像度を台無しにしているバックポートがあったかどうかを調べます。 GoogleとCAFは、安定していない特定のパッチをバックポートすることを好みます。 Stableは、メインラインコミットの解決策を、Googleがバックポートすることを選択した特定のパッチの不在に適応させる必要があることがよくあります。 git show を実行すると、メインラインのコミットを確認できます（メインラインのハッシュは、安定したコミットのコミットメッセージで利用できます）。バックポートが混乱している場合は、変更を破棄するか、メインラインバージョンを使用できます（これは通常行う必要があります）。
• コミットが実行しようとしていることを読み、問題がすでに修正されているかどうかを確認します。 CAFは、アップストリームとは関係なくバグを修正する場合があります。つまり、上記のように、アップストリームの修正を上書きするか、破棄することができます。

それ以外の場合は、CAF / Google / OEMの追加の結果である可能性があります。その場合は、いくつかのものをシャッフルする必要があります。

これがlinux-stablekernel.orgリポジトリのミラーです。 GitHubで、競合解決のためにコミットリストと差分を簡単に検索できます。最初にコミットリストビューに移動し、問題のあるコミットを見つけて元の差分を確認し、それを自分のものと比較することをお勧めします。

URLの例： https://github.com/nathanchance/linux-stable/commits/linux-3.10.y/arch/arm64/mm/mmu.c

コマンドラインからも実行できます：

git log <current_version>..<version_being_added> <path>
git show <hash>

解決策を解決することは、すべてコンテキストに関するものです。常に行う必要があるのは、2つの別々のウィンドウで次のコマンドを実行して、最終的な差分がアップストリームの差分と一致することを確認することです。

git diff HEAD
git diff v$(make kernelversion)..$(git tag --sort=-taggerdate -l v$(make kernelversion | cut -d . -f 1,2)* | head -n1)

再再利用を有効にする

Gitにはrerere（Reuse Recorded Resolutionの略）と呼ばれる機能があります。つまり、競合を検出すると、解決方法を記録して、後で再利用できるようにします。これは、git addを実行するだけでよいため、マージとチェリーピッキングの両方を行う慢性的なリベーサーの両方に特に役立ちます。 &&git –競合は以前に解決した方法で解決されるため、アップストリームの起動をやり直すときに続行します。

カーネルリポジトリで次のコマンドを実行することで有効にできます：

git config rerere.enabled true

コンパイラまたはランタイムエラーが発生したときにGitバイセクトを実行する方法

かなりの数のコミットを追加することを考えると、コンパイラまたはランタイムエラーが発生する可能性が非常に高くなります。諦めるだけでなく、gitの組み込みのバイセクトツールを使用して、問題の根本的な原因を突き止めることができます。理想的には、カーネルバージョンを追加するたびにビルドしてフラッシュするので、必要に応じて二等分するのにかかる時間は短くなりますが、5000のコミットを問題なく二等分できます。

git bisectが行うことは、問題が存在する場所から存在しない場所まで、さまざまなコミットを取得し、コミット範囲を半分にして、ビルドとテストを行い、問題が適切かどうかを通知できるようにすることです。 。問題の原因となるコミットを吐き出すまで、これを続行します。その時点で、修正するか元に戻すことができます。

1. 二等分を開始：git bisect start
2. 現在のリビジョンにbadのラベルを付けます：git bisect bad
3. リビジョンにgoodのラベルを付ける：git bisect good
4. 新しいリビジョンでビルドする
5. 結果に基づいて（問題が存在するかどうかにかかわらず）、gitに次のように伝えます：gitbisectgoodまたはgitbisectbad
6. 問題のコミットが見つかるまで、手順4〜5をすすぎ、繰り返します。
7. 問題のコミットを元に戻すか修正します。

注： マージを適切に二等分するために、すべてのパッチをブランチに適用するには、マージで一時的にgit rebase -i を実行する必要があります。これは、マージを適切に行うことで二等分すると、アップストリームコミットにチェックアウトされることが多く、Android固有のコミットがないことを意味します。 。リクエストに応じてこれについてさらに深く掘り下げることができますが、私を信じてください、それは必要です。問題のあるコミットを特定したら、それを元に戻すか、マージにリベースできます。

アップストリームの更新を潰さないでください

多くの新しい開発者は、管理が「よりクリーン」で「簡単」であるため、これを実行しようとします。これはいくつかの理由でひどいです：

• 権限が失われます。他の開発者にとって、自分の仕事のためにクレジットを奪われるのは不公平です。
• 二等分することは不可能です。一連のコミットを押しつぶし、そのシリーズで何かが問題になっている場合、どのコミットが押しつぶしで問題を引き起こしたかを判断することは不可能です。
• 将来のチェリーピックはより難しくなります。押しつぶされたシリーズでリベースする必要がある場合、競合がどこから発生したかを判断することは困難/不可能です。

タイムリーな更新については、Linuxカーネルメーリングリストに登録してください

アップストリームアップデートがあるたびに通知を受け取るには、linux-kernel-announceリストに登録してください。 。これにより、新しいカーネルがリリースされるたびにメールを受け取ることができるため、できるだけ早く更新してプッシュすることができます。