💡 Quick Fact — How Big Is the Kernel?

As of kernel 6.x, the Linux source tree contains over 35 million lines of code spread across 70,000+ files. Understanding directory layout is not optional — it is your survival skill as a kernel or device driver developer.

kernel/ — The Brain of the OS

This directory contains the core mechanisms that make Linux an OS: the process scheduler, system calls, signals, timers, and kernel threads. Without this, nothing else in the system works.

Notable files every free Linux kernel programming student should know: kernel/sched/core.c (the scheduler), kernel/signal.c (signal handling), kernel/sys.c (system calls).

mm/ — Memory Management

Everything related to RAM lives here — how it is allocated, freed, and shared. Topics like virtual memory, paging, slab allocator, OOM (Out Of Memory) killer, and memory-mapped files are all implemented inside mm/.

In embedded systems, understanding mm/ is critical because you work with constrained RAM and must avoid fragmentation at all costs.

fs/ — Filesystems

Linux supports a huge range of filesystems — ext4, btrfs, tmpfs, FAT, NFS, and many more. Each filesystem is a subdirectory inside fs/. The VFS (Virtual Filesystem Switch) abstraction layer also lives here, which is what allows the same open(), read(), and write() system calls to work regardless of which filesystem is underneath.

Embedded developers often work with fs/squashfs, fs/jffs2, and fs/ubifs for flash storage targets.

drivers/ — Device Drivers

The biggest directory in the entire source tree. It contains device drivers for almost every type of hardware — USB, PCI, I2C, SPI, GPIO, network cards, displays, Bluetooth, and much more. As a student in a free Linux device drivers course, you will spend most of your time here.

Key subdirectories: drivers/bluetooth/, drivers/net/, drivers/gpio/, drivers/i2c/, drivers/spi/.

net/ — Networking Stack

The entire networking stack lives here — TCP/IP, sockets, Bluetooth protocol stack (BlueZ core), WiFi subsystem (mac80211), and netfilter (firewall). If a packet travels through Linux, the code that processes it is inside net/.

For BLE and Bluetooth developers: net/bluetooth/ is where HCI, L2CAP, and the GATT core are implemented at the kernel level.

ipc/ — Inter-Process Communication

This directory contains the kernel-side implementation of shared memory, message queues, and semaphores (both System V IPC and POSIX). When two processes on the same machine need to exchange data, the code that makes it happen lives here.

sound/ — Audio Subsystem

The complete audio subsystem. The modern Linux audio stack is called ALSA (Advanced Linux Sound Architecture). Everything from USB audio to embedded I2S audio codecs is implemented through the sound/ directory.

virt/ — Virtualization

Virtualization support lives here. This is the home of KVM (Kernel-based Virtual Machine) — Linux’s built-in hypervisor that lets virtual machines run at near-native speed. If you have ever used QEMU on Linux, KVM is what makes it fast.

arch/ — CPU Architecture-Specific Code

Each supported CPU family has its own subfolder inside arch/. This is where boot code, memory layout, interrupt handling, and system call entry points differ from one chip family to another. Linux is one of the most ported operating systems in history.

📌 Key Insight — One Kernel Source for Everything

There is one unified kernel source for all platforms. You are not downloading a different kernel for your ARM Raspberry Pi vs your x86 laptop. It is the same source code — compiled differently with architecture-specific code pulled from the right arch/ subfolder. This is what makes the free Linux kernel programming model so powerful and versatile.

crypto/ — Cryptographic Algorithms

Cryptographic algorithms implemented at the kernel level. AES, SHA-256, RSA, ChaCha20 are all here. These are consumed by the networking stack (TLS/IPsec), disk encryption (dm-crypt), and any kernel subsystem that needs secure hashing or encryption.

include/ — Kernel Headers

All architecture-independent kernel header files live here. When you write a kernel module and add #include <linux/module.h>, that file comes from include/linux/module.h. Architecture-specific headers live under arch/<cpu>/include/.

init/ — The Kernel Boot Entry Point

The closest thing the kernel has to a main() function is inside init/main.c. The function is called start_kernel() and it is the first C code the kernel executes after very early architecture-specific assembly boot code.

Studying init/main.c is one of the best ways to understand the kernel boot sequence — you can trace every subsystem being initialized in order just by reading through it.

lib/ — The Kernel’s Standard Library

The kernel cannot use glibc (the C library used by userspace programs), so it has its own implementations inside lib/: string routines, compression/decompression, bitmap operations, CRC algorithms, sorting, and linked list helpers. Unlike a normal shared library, this code is statically compiled directly into the kernel image. There are no .so files in kernel land.

scripts/ — Build and Helper Scripts

Build scripts, Perl scripts, and helper tools. Many are used internally during the kernel build. Others help with checking coding style, static analysis, and finding the right maintainer to send a patch to.

security/ — Linux Security Modules

The kernel’s security framework lives here. LSM (Linux Security Modules) is a flexible hook-based system that lets security policies be enforced at the kernel level without modifying the core kernel code.

tools/ — Userspace Tools Coupled to the Kernel

Userspace tools that interact so deeply with kernel internals that they live inside the kernel source itself. The most famous is perf — the Linux performance profiler. GPIO test tools, USB gadget utilities, and networking tools also live here.

✅ What GPL-2.0 Allows

• Use the kernel freely for any purpose including commercial products
• Study and modify the source code
• Distribute the kernel to others
• Release kernel modules under a dual license (e.g. BSD/GPL)

⚠ What GPL-2.0 Requires

• If you modify the kernel and distribute a product, you must share your source code
• Derivative works must also be released under GPL-2.0
• You cannot secretly keep kernel modifications proprietary

⚠ Important for Embedded Linux Developers

If your company builds a product using the Linux kernel and you modify kernel code — you are legally required to release those modifications under GPL-2.0 when you distribute the product. Many responsible embedded Linux companies publish their kernel patches publicly.

ctags — Function and Variable Index

Creates an index of every function and variable in the source. Works with Vim, VS Code, Emacs, and most editors for instant jump-to-definition navigation.

cscope — Interactive Source Browser

An interactive browser for the kernel source. Lets you find all callers of a function, all places a variable is used, and all files that include a particular header.

Elixir Cross Referencer — Best Web-Based Tool

Available at elixir.bootlin.com — browse any kernel version online with one click, jump to any function definition, see all callers, no local setup needed. Highly recommended for beginners in this free Linux kernel programming course because there is nothing to install.

VS Code + clangd — Modern IDE Approach

Use VS Code with the clangd language server extension and a compile_commands.json file generated during the kernel build. This gives you intelligent code navigation, inline documentation, and error detection as you type.

Q1. Where does the Linux kernel’s boot sequence begin in C code?

The kernel’s early C entry point is the start_kernel() function located in init/main.c. Before this, architecture-specific assembly code inside arch/<cpu>/ handles very early CPU initialization. Once start_kernel() is called, it initializes every major kernel subsystem one by one in a fixed, documented sequence.

Q2. Is there a separate Linux kernel source for embedded devices vs servers?

No. There is a single unified Linux kernel source tree used for everything from a tiny IoT sensor to a cloud server with 1000+ CPU cores. The differences come from how the kernel is configured and compiled — which features are enabled, which drivers are included, and which architecture folder in arch/ is targeted.

Q3. What is an LSM and name three examples available in the Linux kernel?

LSM stands for Linux Security Module. It is a hook-based framework inside the security/ directory that lets security policies be enforced at the kernel level without touching core kernel code. Three examples: SELinux (used on Android and RHEL), AppArmor (default on Ubuntu), and Landlock (added in kernel 5.13, allows userspace apps to sandbox themselves without root privileges).

Q4. Can a company legally ship a closed-source Linux kernel driver?

This is a legally grey area. The kernel is GPL-2.0, which technically requires derivative works to also be GPL-2.0. Some companies release proprietary drivers as Loadable Kernel Modules (LKMs) anyway. Whether this truly complies with the GPL-2.0 is debated. The kernel community officially marks such modules as “tainted” and strongly discourages the practice. The safest approaches are to open-source the driver or use an official dual-license arrangement.

Q5. If you write a Bluetooth kernel driver, in which two directories would your code live?

Protocol-level code (HCI, L2CAP, GATT core) belongs in net/bluetooth/. The hardware-specific driver for a particular chip (a USB Bluetooth dongle, a UART-attached controller) belongs in drivers/bluetooth/. This clean separation between protocol logic and hardware-specific logic is a key design principle of the Linux kernel source tree.

Q6. Why cannot the kernel use glibc or any standard C library?

glibc is a userspace library that depends on the kernel itself for services like mmap() and read(). The kernel is the lowest software layer — nothing underneath it can provide those services. So the kernel has its own implementations inside lib/: string routines, sorting, compression, CRC, and bitmap operations. Unlike glibc, all of this code is statically compiled into the kernel image.

Q7. What is the difference between arch/ and drivers/ in the kernel source tree?

arch/ contains code that is specific to a CPU family — how that architecture boots, handles interrupts, and implements system call entry. drivers/ contains code for specific hardware devices and is largely architecture-independent. A single Bluetooth driver in drivers/bluetooth/ can work on x86, ARM64, and RISC-V without modification because the arch/ layer abstracts all CPU differences away.