kbuild 與設備樹相比如何？
我知道 KConfig 用於在 Linux 核心編譯開始時調整 C 預處理器。並且設備樹用於在執行時為編譯的核心提供有關硬體的描述。
這兩個可配置特性如何重疊？
例如，兩者都提供有關內部 CPU 詳細資訊和外部外圍設備驅動程序的資訊。我想設備樹中提到的任何外圍設備都必須獲得之前在 .config 文件中聲明的驅動程序。我也可以猜到，如果驅動程序已被編譯為內置，它將不會再次作為模組載入……但是有什麼更詳細的細節呢？
編譯時核心配置可以指定是否包含核心原始碼樹中包含的每個標準驅動程序，如何包含這些驅動程序（作為內置或可載入模組），以及與例如相關的許多其他參數在編譯核心時將使用什麼樣的優化和其他選擇（例如，針對特定的 CPU 模型進行優化，或者盡可能通用，或者是否預設啟用 Spectre/Meltdown 安全緩解等功能）。
如果編譯時核心配置設置得足夠通用，那麼同一個核心可以在同一個處理器體系結構內用於大量不同的系統。
另一方面，設備樹是關於核心目前執行的實際硬體。對於嵌入式系統和其他沒有自動探測技術（如 ACPI 或 PCI(e)）的系統，設備樹將指定特定硬體組件所在的確切 I/O 或記憶體地址，以便驅動程序能夠找到和使用那些硬體組件。
即使設備樹描述了一個特定的硬體組件存在以及如何訪問它，如果在編譯時禁用它的必要驅動程序，那麼核心將無法使用它，除非稍後單獨添加驅動程序模組。或者，如果核心是用完全單一的配置編譯的，不支持可載入模組，那麼該核心將根本無法使用特定設備，除非它的驅動程序包含在核心編譯中。
如果硬體組件的驅動程序包含在核心配置中（內置或作為可載入模組）但在設備樹中沒有它的資訊（並且硬體架構不包括標準檢測機制），那麼核心將不知道硬體組件的存在。例如，如果設備樹錯誤地將顯示控制器的幀緩衝區區域指定為正常可用 RAM，那麼您可能會隨機顯示碰巧儲存在顯示控制器的預設幀緩衝區區域中的任何字節，作為像素“雜訊”的混亂。或者，如果顯示控制器需要特定的初始化才能開始工作，您可能根本不會得到任何輸出。
換句話說，設備樹的目的是告訴核心系統的各種硬體特性在處理器的地址空間中的位置，既使核心能夠將正確的驅動程序指向正確的物理硬體，又告訴核心它不應該嘗試將地址空間的哪些部分用作正常 RAM。