LinuxカーネルKconfigでtristatevs boolを使用するのはなぜですか？
これが、なぜ一方を他方を使用することを選択するのかについての私の現在の理解です。確認または修正していただけますか？
- 実行時とコンパイル時：実行時までこれを有効にするかどうかわからない場合は、トライステートを使用してください。それ以外の場合は、コンパイル時に知っているので、boolを使用します。あなたが
#ifdef周囲のコードB内のオプションのコードA（GPUサポートなどのボーナス機能を含む）の場合、モジュールB全体をトライステートとして宣言できたとしても、ifdefはコンパイル時に評価されます。 - 反復速度：新しいコードを開発している場合、それをモジュールとして宣言すると、システム全体を再起動しなくても、古いバージョンをすばやくアンロードして、新しくコンパイルしたバージョンをリロードできます。
- 煩わしさ：一部のコードは、すでに実行中のカーネルに動的に追加するには非常に破壊的であるため（Symmetric-Multi-Processingなど）、常にブール値になります。
私がここで見逃している他の要因はありますか？私が行方不明になっているのを見ることができた要因は
- パフォーマンス
- セキュリティ
- 経験則（例：「トライステートを使用するには必要でない限り、常にブール値を使用してください」）
その他の説明、メモ、リンク、および考えをいただければ幸いです。ありがとう！
https://www.linuxjournal.com/content/kbuild-linux-kernel-build-system からの引用
カーネル内のすべてをモジュールとしてコンパイルできるわけではありません。
多くの機能は非常に煩わしいため、コンパイル時にカーネルがそれらをサポートするかどうかを決定する必要があります。たとえば、実行中のカーネルに対称型マルチプロセッシング（SMP）またはカーネルプリエンプションのサポートを追加することはできません。したがって、ブール構成シンボルを使用することは、これらの種類の機能にとって意味があります。
モジュールとしてコンパイルできるほとんどの機能は、コンパイル時にカーネルに追加することもできます。これがトライステートシンボルが存在する理由です。機能の組み込み（y）をモジュールとしてコンパイルするか（m）、まったくコンパイルしないか（n）を決定するためです。
これは明らかだと思います。選択肢が2つしかない場合はブール値を使用し、選択肢が3つある場合はトライステートを使用します。他のすべては意味がありません。