3

I read that Linux device tree as a datastructure defining the hardware of the device (components present such as I2C, USB etc)

Question: How is this different then .config file that tells make-file of the device drivers to be compiled for kernel i.e what modules in the device are present?

BiologyEnthusiast
  • 55
  • 5
  • Drivers compiled into the kernel have nothing to do with devices actually present on the system. Of course, both must be present to have a working device. – stark Jan 12 '21 at 17:10
  • 1
    Device Tree is platform description of the **physical devices** present on it. Configuration file is about **device drivers** that are present in the software and may drive the devices on the platform the software is run on. – 0andriy Jan 12 '21 at 19:06
  • @0andriy i still dont understand the motivation to distinguish between the two. What value device tree bring that device drivers dont bring? – BiologyEnthusiast Jan 12 '21 at 20:37
  • @stark i dont understand why drlvers compiled into the kernel have nothing to do with devices present on the system. Without the drivers devices have no meaning.. – BiologyEnthusiast Jan 12 '21 at 20:38

1 Answers1

3

Device Tree Vs .Config file | Are they different?

Yes, they are different, and serve different purposes at different times.

The .config file is an integral component of the kernel's build procedure. The .config file is data to control the building of the kernel, that is, its contents is used by makefiles.
A .config file could be customized to build a kernel specifically for just one specific version of a SBC.
Or the .config file could specify a kernel with a plethora of features, subsystems, and drivers for a variety of capabilities and support families of SBCs. Such a kernel image could be booted by any compatible board.

A .config file consists of lines of configuration symbols, e.g. CONFIG_xxx=....
Assignments of strings or numeric constants are rare, but do exist, e.g. CONFIG_LOCALVERSION="my_version" and CONFIG_INIT_ENV_ARG_LIMIT=32.
Typically the assignment is y to affirm that the configuration item is enabled.
A configuration item that is disabled is not asigned n, but rather commented out, e.g. # CONFIG_xxx is not set.
A configuration item that is "tristate" can be assigned m to affirm that the configuration item is enabled but built as a loadable module (rather than statically linked, aka built-in).

Note that although kernel source code may contain preprocessor directives (e.g. #ifdef for conditional compilation) utilizing CONFIG_xxx symbols that appear identical to the .config symbols, these symbols are not equivalent.
Kernel source code does not read or use the .config file.
Rather the .config file is converted into a C header file of preprocessor statements with a #define for each enabled CONFIG_xxx line, and stored in include/generated/autoconf.h (the exact path has changed for older versions).
It is the autoconf.h file that defines the CONFIG_xxx symbols used in kernel source code.
Note that a tristate configuration item that is assigned m in the .config becomes #define CONFIG_xxx_MODULE 1 in the autoconf.h file, rather than just #define CONFIG_xxx 1.

Device Tree is used by only a handful of CPU architectures in the Linux kernel.
The Device Tree (blob) is data to inform the executing kernel of its hardware environment (i.e. the target board). It also informs the kernel which device drivers to initialize (using the compatible property string).
Regardless of how many device drivers are statically linked into the kernel or available as loadable modules, a device driver is only initialized if there is a DT device node that references that device driver (e.g. see Driver code in kernel module doesn't execute?).
(The exception to that are buses that have self-identifying devices such as USB and PCI/PCIe, which have different procedures for initializing their device drivers.)

The Device Tree goes through several transformations before it is utilized by an executing kernel.
The DT source file(s) for a specific board exist as one .dts and optional .dtsi (included) files that are compiled into a .dtb file, aka DT blob.
It is the DT blob that is loaded with the kernel during boot, and then converted from its "flat" organization into a tree structure in kernel memory.
Kernel routines, e.g. device drivers, access the DT using methods provided by of_*() routines (where the "of" is for Open Foundation).

sawdust
  • 16,103
  • 3
  • 40
  • 50
  • Quite nice explanation! I am slightly confused perhaps of the wording isnt `Or the .config file could specify a kernel with a plethora of features, subsystems, and drivers for a variety of capabilities and support families of SBCs.` and .`Regardless of how many device drivers are statically linked into the kernel or available as loadable modules, a device driver is only initialized if there is a DT device node that references that device driver.` pretty much the same thing? I can manually choose devices to be initialized by issuing .`make menuconfig` command. I shall read the answer again. – BiologyEnthusiast Jan 13 '21 at 13:15
  • 1
    @BiologyEnthusiast -- *"I can manually choose devices to be initialized by issuing .`make menuconfig` command"* -- No, that will only control what is built. Which drivers are *initialized* is determined by the board's DT. See https://stackoverflow.com/questions/26840267/driver-code-in-kernel-module-doesnt-execute A DT will only have nodes for devices that actually exist on the board (which should be a subset of the drivers built)! The two sentences you quote are not the same, but are complementary. – sawdust Jan 14 '21 at 22:16
  • makes soo much sense! I thought what is built is also what is initialized! The sentence `which should be a subset of the drivers built` helped me understand it! Thanks! – BiologyEnthusiast Jan 17 '21 at 13:06