Why the Linux Kernel is So Versatile in the Face of Ever-Changing Devices

Everyone knows that the Linux kernel has a very wide range of applications, permeating many fields of life and production. In the consumer electronics sector, it supports numerous products such as smartphones, smart TVs, smartwatches, and smart locks, enabling functions like communication, entertainment, and health monitoring. In industrial scenarios, industrial PLCs, in-vehicle infotainment systems, and medical devices rely on it to ensure stable operation and precise control. In the fields of network security and development, routers, firewalls, development boards, and server hardware are also centered around it. Additionally, it covers cloud computing nodes, gaming consoles, smart projectors, and more, fully adapting to diverse application needs.Below is a table I organized showing the application scenarios of the Linux kernel, illustrating its omnipresence.

Product Category Specific Category Product Examples Core Functions / Application Scenario Description
Consumer Electronics Smartphones Samsung Galaxy S24 Series, Huawei P70 Series, Xiaomi 14 Ultra, Google Pixel 9 Pro, OnePlus 12 Based on Android (Linux kernel), supports 5G/6G networks, high-definition imaging, multitasking, mobile application ecosystem
Tablets Samsung Galaxy Tab S10+, Huawei MatePad Pro 13.2 inches, Xiaomi Pad 6 Max, iPad (Note: iPadOS is based on Apple’s self-developed kernel, here we supplement with Android tablets that conform to the Linux kernel) Supports large-screen office work, audio-visual entertainment, stylus interaction, runs Android ecosystem applications, adapts to multitasking split-screen
Smartwatches / Bands Huawei Watch GT 4, Samsung Galaxy Watch 6, Xiaomi Watch S3, Amazfit GTR 6 Pro Based on embedded Linux / Android Wear OS, supports health monitoring (heart rate, blood oxygen), exercise recording, Bluetooth calls
Smart TVs / Set-top Boxes Sony BRAVIA X95L Series, TCL Q10H Mini LED TV, Xiaomi TV S Pro 85 inches, Tmall Magic Box 6Pro Equipped with an embedded Linux system, supports 4K/8K decoding, online video (such as Netflix / iQIYI), smart home interconnectivity
Smart Speakers Xiaomi AI Speaker HD, Tmall Genie X5, Baidu Xiaodu Smart Speaker MAX, Amazon Echo Dot (5th Generation) Based on embedded Linux, enabling voice interaction, music playback, smart home control (such as linking lights / air conditioning)
Smart Home Devices Xiaomi Smart Camera 2K PTZ Version, Huawei HiLink Smart Socket, Philips Hue Smart Bulb, Ecovacs Deebot X3 Pro Embedded Linux system supports device networking, remote control (APP linkage), automated scene triggering (such as human body sensing to turn on lights)
Industrial and Professional Equipment Industrial PLC (Programmable Logic Controller) Siemens SIMATIC S7-1200/S7-300, Schneider M258 Series, Omron CP1H Series, Mitsubishi FX5U Series Real-time systems based on embedded Linux for industrial automation control (such as starting/stopping production lines, adjusting equipment parameters)
Industrial Touch Screens (HMI) Weintek MT8102iE, Delta DOP-107CV, Siemens TP170B Human-machine interaction systems based on the Linux kernel, displaying industrial equipment status, parameter settings, fault alarms
In-Vehicle Infotainment Systems Tesla Model 3/Y Central Control System, BMW iDrive 9, Audi MMI, Mercedes-Benz MBUX, BYD DiLink 5.0 Based on a customized Linux kernel, supports navigation, in-car music, car-machine interconnectivity (CarPlay/HiCar), vehicle status monitoring
Medical Devices Mindray BeneView T1 Monitor, Philips EPIQ 5 Ultrasound Diagnostic System, Siemens X-ray Control System Embedded Linux ensures data collection (such as heart rate / blood pressure), image processing, medical data storage and transmission
Scientific Computing / Supercomputers Sunway TaihuLight Supercomputer, Lenovo Deep Computing X1000, Inspur K1 Power Series, National Supercomputing Center “Tianhe” Series (some nodes) Based on Linux server systems, supporting large-scale scientific computing (such as meteorological simulation, quantum mechanics calculations)
Network and Security Devices Routers / Switches Huawei AR650 Series Enterprise Routers, Cisco Catalyst 9300 Switches, TP-Link TL-WDR7660 Home Routers (OpenWrt compatible) Network systems based on the Linux kernel, enabling data forwarding, bandwidth management, VPN encryption, local area network networking
Network Firewalls Huawei USG6000E Series, Sangfor AF Series, Qihoo 360 Tianqing Hanma USG, Palo Alto Networks PA-220 Linux systems support firewall rules (port filtering / IP blocking), intrusion detection (IDS), VPN secure tunnels
Load Balancing Devices Sangfor AD Series, F5 BIG-IP, Huawei CloudEngine 16800 Series Load Balancing Modules Optimized based on the Linux kernel, enabling server traffic distribution, automatic failover, improving service availability
Development and Server Equipment Development Boards Raspberry Pi 5, BeagleBone Black, Arduino Portenta H7, NVIDIA Jetson Nano (edge computing development board) Equipped with Linux systems (such as Raspbian/Ubuntu Server), used for programming learning, embedded project development (such as robotics, IoT prototypes)
Hardware Devices Corresponding to Server Operating Systems Dell PowerEdge R760 Server, HP ProLiant DL380 Gen11, Huawei FusionServer Pro 2288H V6 Running Linux server systems (such as RHEL/Ubuntu Server/openEuler), used for enterprise data storage, application deployment
Cloud Computing Platform Hardware Nodes Alibaba Cloud ECS Servers (physical nodes), Tencent Cloud CVM physical machines, Amazon AWS EC2 physical nodes Cloud operating systems based on the Linux kernel (such as Alibaba Cloud Feitian, Tencent Cloud TencentOS), supporting cloud servers, container services
Other Embedded Devices Game Consoles Sony PlayStation 5 (system based on FreeBSD, note: FreeBSD and Linux both belong to the Unix family, here we supplement with devices that conform to the Linux kernel: such as Valve Steam Deck handheld) Steam Deck runs on SteamOS based on Arch Linux, supporting PC game operation, handheld interactive operation
Smart Projectors XGIMI H6, JmGO N1 Ultra, BenQ W1800M Embedded Linux system supports projection quality adjustment, smart keystone correction, online video playback (such as Tencent Video TV version)
Smart Locks Xiaomi Fully Automatic Smart Lock M20, Dessmann Q50F Max, Kaadas K20-V Based on the Linux kernel, enabling fingerprint/password unlocking, APP remote control, abnormal alarms (such as lock tampering alerts)

Now, the question arises.In the various scenarios above, there are different motherboards and different external devices. How can the Linux kernel foresee and provide excellent versatility for all these devices?Before revealing the answer, let’s conduct a “thought experiment”. If I were Linus, and I had to design a sufficiently versatile system from scratch, how would I do it? Clearly, to achieve versatility, we need a capability that allows us to know what devices our system is about to run with. Of course, I am not a deity, and I do not have superpowers, so this capability can only be a mechanism. Therefore, I want to know what external devices are available, and there are evidently two ways: the first way is for others to directly tell me what devices are available; the second way is for me to actively find out what devices are available. It may sound a bit redundant, but in fact, this is exactly how the Linux kernel operates, and we will analyze it step by step.The two methods used by Linux are: the first method, where others tell me what devices are available, mainly relies on the DTS (Device Tree Source) capability; the second method, where it actively finds out what devices are available, mainly relies on ACPI + PCI/PCIe bootstrapping.

The First Method: Others Tell Me What Devices Are Available: The DTS Mechanism

The Essence of DTS from the Kernel’s Perspective

  1. DTS (Device Tree Source) is compiled by dtc to generate DTB (Device Tree Blob);

  2. In the early stages of kernel startup (start_kernel → setup_arch → unflatten_device_tree), the DTB is unpacked into a linked list of platform_device, which is used for subsequent platform/bus driver matching;

  3. Therefore,“DTS is needed” = “A static hardware description table is needed to generate platform_device”.If the architecture/firmware can already provide the same information, then DTS is no longer needed.

When Does the Kernel “Depend on” DTS?

  1. Architecture mandatesARM, ARM64, RISC-V, PowerPC, MIPS, Xtensa, etc. set DEVICE_TREE as ARCH_REQUIRE; failing to pass a valid DTB will directly cause a panic (early_printk prompts “No DTB passed”).

  2. Extremely simplified firmwareEmbedded boards often only run a 20 KB BootROM + U-Boot, without ACPI/PNP/BIOS,all addresses, interrupts, clocks, and GPIO numbers can only be communicated to the kernel via the DTB.

  3. Dynamic peripheral topologyThe same SoC can have over 100 different boards: memory capacity, changing PHY, changing PMU, changing NAND pins.Manufacturers only need to modify the .dts file,while the kernel image remains unchanged, satisfying the requirement that “the same zImage supports multiple hardware.”

  4. Runtime expansionWith Device-Tree-Overlay (.dtbo), FPGA regions, Raspberry Pi HATs, and BeagleBone capes can be dynamically loaded without rebooting.This is a lightweight solution outside the ACPI hot-plug model.

The Second Method: Actively Finding Out What Devices Are Available: ACPI + PCI/PCIe Bootstrapping

Why x86 “Almost Never” Uses DTS

  1. ACPI serves as a “high-level device tree”

  • x86 uniformly provides ACPI tables (DSDT/SSDT/MADT/SRAT…) via BIOS/UEFI,and the kernel enumerates IRQ, IO-APIC, GPIO, I²C, PWM, PMIC, PCI root buses through the ACPI namespace;

  • ACPI also carries _OSI, _PRD, _PSD and other power/performance states,which the DTB syntax currently cannot express.

  • PCI/PCIe self-enumeration90% of x86 peripherals are connected via PCIe,the Configuration Space’s BAR automatically provides addresses, interrupts, and DMA capabilities, allowing the kernel to follow the PCI driver model without needing to hard-code in a static table.

  • Traditional compatibility requirementsPCs need to run Windows, and Windows only recognizes ACPI/PNP0xxx, so OEMs cannot be asked to write DTS.Thus, Linux/x86 must also adhere to the same firmware interface.

  • Kernel configuration switchesCONFIG_X86_DEVINIT is disabled by default, even if manually enabled and a DTB is passed,x86’s early_quirks, ACPI, and PCI subsystems will still ignore most nodes, treating the DTB as “supplementary information” (such as GPIO number mapping, early serial port addresses), rather than the primary enumeration source.

  • Simple Summary of the Two Methods

    Dimension ARM / Embedded x86/PC
    Firmware Minimal BootROM + U-Boot UEFI/BIOS + ACPI
    Bus AMBA, on-chip peripherals, no self-enumeration PCIe dominates, self-enumerating
    Enumeration Method Must be statically described → DTS Via ACPI namespace + PCI configuration space
    Kernel Switch CONFIG_USE_OF forced to y CONFIG_X86_DEVINIT default n
    Image Strategy Same zImage + multiple DTBs Single image, relying on BIOS/ACPI data
    Dynamic Expansion DT Overlay (.dtbo) ACPI hot-plug/UEFI Capsule
    Typical Result Changing hardware only requires modifying .dts Changing hardware only requires modifying BIOS/ACPI, OS remains unchanged

    The Fundamental Reason the Linux Kernel “Needs DTS” isThat Firmware Does Not Provide Sufficient and Standardized Hardware Descriptions; x86, due to having ACPI and PCIe self-enumeration, naturally meets the kernel’s enumeration needs, so DTS is an option, not a necessity.

    Leave a Comment