Japanese Stable CLIP を試してみた

Upstream の更新に追従する

https://forum.xda-developers.com/t/guide-working-with-android-kernel-from-scratch.3909887/

このガイドにあった、Upstreaming your kernel をやってみます。

というのも、Nokia 7.2 のカーネルソースは 4.4.153 でした。おそらく、android 9 のカーネルのバージョンだったと思います。android 10 では 4.4.192 とかだったような・・・

なので、まずはそこを目標にしてみたいと思います。


・・・なんか XDA がおかしいですね。フォーラムのシステムを変更したらしく、一部で動作不良を起こしている感じでしょうか。


といっても、今回は CAF のカーネルをベースにしているので、やることと言ったらカーネルソースのトップディレクトリで

git merge v4.4.154

と実行するだけ。これで 4.4.153 から 4.4.154 の変更点を取り込んでくれます。

・・・が、そう簡単にはいきません。

きっと、こんな風に CONFLICT します。これは、merge しようとする変更点が、別の変更と重複していて、自動的に解決できない (git では判断できない) となったことを示します。
この場合は、人の目で見て修正してあげます。
該当ファイルをエディタで開いて修正、でもいいのですが、まずはどこが重複したのかを確認します。上記の場合、
git diff arch/arm64/mm/init.c
とコマンドを実行すると、
こんな風に重複箇所が表示されます。<<<<<<< HEAD と ======== で囲まれた箇所がローカルのコード、======== から >>>>>>>> v4.4.154 で囲まれた箇所がマージしようとしたコードです。
ただ、これはあくまで重複した箇所を示しているのみです。同じファイルでも、重複せずに適用可能な差分については適用しています。なので、単純に変更を破棄するだけでは整合性が取れないので、ビルドに失敗する可能性が大です。マージしようとする変更を有効にする(ローカルの変更を破棄する)場合でも、他の関連するコードはローカルにあったコードに依存している可能性があります。
なお、ローカルの変更を破棄して(この場合) 4.4.154 のファイルに置き換える場合は、
git checkout arch/arm64/mm/init.c --theirs
反対に、4.4.154 の変更を破棄してローカルのファイルを正とする場合は、
git checkout arch/arm64/mm/init.c --ours
というコマンドが使用できます。
新旧比較して修正する場合、git mergetool というコマンドを使用することができますが、こちらはまた機会があれば使ってみます。

C のソースが対象になっている場合、関連するヘッダーファイルにも飛び火する可能性も高いと思います。その辺を修正したら、変更したファイルを git add して git commit して、やっと 4.4.154 への更新が完了です。

CONFLICT しない場合もあるんですけどね。

コメント