I know KConfig serves to tune the C preprocessor, at the start of the Linux kernel compilation. And that the device tree is used to give a compiled kernel a description about hardware at runtime.

How do these two configurability features overlap?

Both give information about intrinsic CPU details and drivers for external peripherals, for example. I imagine that any peripheral mentionned in the device tree must have gotten its driver previously declared in the .config file. I can guess too that if a driver has been compiled as built-in, it will not be loaded as a module again... but what finer details are there?

1 Answer 1


A compile-time kernel configuration can specify whether or not include each of the standard drivers included in the kernel source tree, how those drivers will be included (as built-in or as loadable modules), and a number of other parameters related to e.g. what kind of optimizations and other choices will be used in compiling the kernel (e.g. optimize to specific CPU models, or to be as generic as possible, or whether or not enable some features like Spectre/Meltdown security mitigations by default or not).

If a compile-time kernel configuration is set generic enough, the same kernel can be used with a large number of different systems within the same processor architecture.

On the other hand, the device tree is about the actual hardware the kernel is currently running on. For embedded systems and other systems with no autoprobeable technologies like ACPI or PCI(e), the device tree will specify the exact I/O or memory addresses specific hardware components will be found at, so that the drivers will be able to find and use those hardware components.

Even if the device tree describes a particular hardware component exists and how it can be accessed, if the necessary driver for it is disabled at compile-time, then the kernel will be unable to use it unless the driver module is added separately later. Or if the kernel is compiled with a completely monolithic configuration with no loadable module support, then that kernel won't be able to use a particular device at all unless the driver for it is included in the kernel compilation.

If a driver for a hardware component is included in kernel configuration (either built-in or as a loadable module) but there is no information for it in the device tree (and the hardware architecture does not include standard detection mechanisms), then the kernel will be unaware of the existence of the hardware component. For example, if the device tree incorrectly specifies the display controller's framebuffer area as regular usable RAM, then you might get a random display of whatever bytes happen to get stored in the display controller's default framebuffer area, as a jumble of pixel "noise". Or, if the display controller needs a specific initialization to start working, you might get no output at all.

In other words, the purpose of the device tree is to tell the kernel where the various hardware features of the system are located in the processor's address space(s), both to enable the kernel to point the correct drivers to correct physical hardware, and to tell the kernel which parts of address space it should not attempt to use as regular RAM.

  • Nice information, thank you. It stems from your answer that the two features are complementary, and do not overlap.
    – AIDoubt
    Dec 13, 2019 at 0:09

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .