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

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デバイスで実行されているカーネルバージョンを把握する必要があります。

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

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チェリーピック..

例：

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

行く

フォーマット：

マージする

例：

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 .. git show ..

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

git diff HEAD git diff v $（make kernelversion）.. $（git tag --sort = -taggerdate -l v $（make kernelversion |cut-d。-f1,2）* | head -n1）

rerereを有効にする

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に次のように伝えます：git bisectgoodまたはgitbisect bad
6. 問題のコミットが見つかるまで、手順4〜5をすすぎ、繰り返します。
7. 問題のコミットを元に戻すか修正します。

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

アップストリームの更新を押しつぶさないでください

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

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

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

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