Linux カーネルのモジュールが非常に「脆弱」であり、再コンパイルが頻繁に必要になることに少し驚いています。2 つの異なるマシン (gcc の異なるバージョンなど) で同じソース ツリーを使用すると、カーネル (マシン B) で動作しないモジュール (マシン A) が生成されます。
no symbol version for module_layout悪名高いエラーメッセージが必要ない場合は、ダミーのシステムコールを追加すると、再コンパイルが必要になるようです。
さらに驚いたのは、kernel/ に単なる .c ファイルを追加したことです。このファイルは、ABI に触れません (つまり、内部構造が何であれ、エクスポートも使用も更新もされないスタンドアロン関数)。
その新しい .c ファイルにダミーのテキスト文字列を追加すると、すべてのモジュールは変更されません。
では、ここでのルールと理論的根拠は正確には何ですか? (問題がある場合は、x86、32 ビット アーキテクチャに焦点を当てています)
カーネルと (ロード可能な) モジュールを再構築するというコンパイルの側面に過度に集中し、リンクを忘れているようです。「再コンパイル」が必要であると述べたとき、あなたは誇張している可能性があると思います。
さらに驚いたのは、kernel/ に単なる .c ファイルを追加することです。これは、ABI に触れません (つまり、内部構造が何であれ、エクスポート、使用、または更新されないスタンドアロン関数)。
.cファイル (別名ソース モジュール) をカーネルに追加すると、その新しくコンパイルされたオブジェクト ファイルは、リンカーを使用して新しいカーネル イメージを構築する必要があります。どのグローバル カーネル シンボルが移動したか、または移動しなかったかの評価がないため、結果としてすべての (ロード可能な) モジュールを新しいシンボル マップで再構築 (実際には再リンクのみ) する必要があります。すべてのカーネル モジュールの「再コンパイル」は必要ありません。.oオブジェクト ファイルだけを、新しいカーネル シンボル マップを使用してロード可能なモジュールに再構築する必要があります。
(ロード可能な) モジュールが一致するカーネルとシンボル マップで実行されていることを確認するために、カーネル モジュールのロード時にバージョン管理とビルド情報が検証されます。「壊れやすい」と呼ばれるものは、実際には、特権モードで実行されるコードの整合性を確保するためのセキュリティ対策です。