私は独自のモジュールを作成し、このモジュールをカーネルソースコードに追加し、システムコールを実装するという実践を実証する必要があります。 Ubuntuは3.16カーネルを使用していますが、ソースからカーネルをインストールするのに約2時間かかりました。
新しくインストールされたカーネルを定期的に使用する予定がないため、ソースからカーネルの一部（不要なドライバなど）を削除して時間を節約できますか？それではどうですか？
ベストアンサー1
コメントで述べたように、make -j4保持しているCPUコアの数と同じか少し高い数字を使用する必要があります。
ローカル構成の変更
次のガイドラインは、アップストリームでカーネルを構築するためのものです。個人的にこれが一番簡単だと思います。 Ubuntuパッチが適用されたツリーを取得する方法がわかりません。このようにビルドする準備ができました。
（1）理論的に、より合理的な期間にわたってテストするためにカーネルを構築する方法は次のとおりです。
cp /boot/config-`uname -r` .config
新しいものを有効にする必要はありません。したがって、唯一の問題は、名前を変更すると操作が中断されることです。
make oldnoconfig
現在ロードされていないすべてのモジュールが無効になりました。 （必要なすべてのUSBデバイスを接続していることを確認してください...）：
make localmodconfig
最近私にうまくいきましたので役に立ちます。前回試してみましたがあまり良くありませんでした。
1時間程度から10分程度に短縮したようです。make localmodconfigそれは私が必要としない膨大な量のものを作っているにもかかわらず。OTOHは実際にこれらの項目（例make xconfig：）を見つけて無効にするのに時間がかかります（または望むものを誤って無効にした場合は時間がかかります）。する必要）。
私はその存在がそれほど価値があることを知りたいです。ただそれがあなたを幸せにするという保証はありません。
（2）各プロジェクトを構築するのに2時間かかるとは思いません。改訂するあなたの「モジュール」に。 （新しいシステムコールを実装する場合は、実際に組み込み関数でなければなりません。） make変更されたファイルのみが再コンパイルされ、カーネルバイナリに組み込まれます。したがって、Kconfigを正しく設定するのが大きすぎる問題であれば、ビルドの最初の2時間はそれほど悪くないかもしれません。
展開カーネルソースパッケージを使用してビルドすると、この問題が発生することがあります。 （手動ビルドに切り替えるか、ソースコードパッケージを使用してデプロイをだますことができますccache）。あるいは、変更により、残念ながら多くのソースファイルに含まれるヘッダーファイルが変更される可能性があります。
それにもかかわらず、別のカーネルバージョンに移植、実行、および他のビルドオプションをテストしたい場合は、カスタムgit bisectKconfig（たとえば、より小さなKconfig）を作成すると便利です。