Chapter 2 — Kernel Configuration
Lecture 19 of Series
Hands-On Linux Kernel Configuration:
Real CONFIG Options Explained
Walk through ten real kernel configuration options, understand what each CONFIG symbol
actually does inside the kernel, and learn which settings are right for embedded systems,
development VMs, and production servers. Updated for Linux 6.x.
🎯 What This Lecture Covers
In Lecture 18 we learned how the menuconfig system works — symbols, Kconfig, Kbuild,
and the .config file. Now we go hands-on. We will walk through ten
real configuration options that every Linux kernel developer should know. For each one
we cover: what the option does, where to find it in menuconfig, how it changed or
stayed the same in Linux 6.x, and the right setting depending on your use case.
📌 Keywords for This Lecture
CONFIG_IKCONFIG
CONFIG_IKCONFIG_PROC
CONFIG_LOCALVERSION
CONFIG_SECURITY LSM
CONFIG_UIO embedded linux
kernel module vs built-in
linux kernel development free course
CONFIG_DEBUG_STACK_USAGE
embedded linux kernel config
1. How to Navigate Any Kernel Config Option
Before diving into specific options, here is the method that works for every option
you will ever encounter — whether in this course or in a real project.
3-Step Method for Any Kernel Config Option
──────────────────────────────────────────────────────────────────────────
Every option has a menu path (e.g. General Setup → Kernel .config support)
If you don’t know the path, press / (forward slash) in menuconfig to
SEARCH by CONFIG name or keyword.Example: Press / → type IKCONFIG → press Enter
menuconfig shows you exactly where it lives in the tree.Step 2 — READ THE HELP
──────────────────────────────────────────────────────────────────────────
Highlight the option → press H (or select < Help >)
The help screen shows:
• What the option does
• Its exact CONFIG_XXX name
• Dependencies (what other options it needs)
• Whether it can be a module or must be built-inStep 3 — CHOOSE y / m / n
──────────────────────────────────────────────────────────────────────────
Press SPACE to cycle: off → module → built-in → off
(Tristate options cycle through all three. Boolean only toggle on/off.)
Press Y to force built-in.
Press M to force module.
Press N to disable.Then SAVE on exit. Your choice appears in .config immediately.
2. CONFIG_LOCALVERSION — Stamp Your Build
CONFIG_LOCALVERSION
Type: String
Symbol in menuconfig: (…)
Linux 6.x: Unchanged
Run uname -r on any Linux system and you see the kernel release string —
something like 6.8.0-41-generic. The CONFIG_LOCALVERSION
option lets you append your own custom string to this release identifier.
This is more useful than it sounds. In embedded development you often have many custom
kernel builds deployed across multiple devices. A meaningful LOCALVERSION
string lets you instantly identify which build is on which device just by running
uname -r — no need to check files or logs.
# In menuconfig: General Setup → Local version - append to kernel release
# Type your string at the prompt (the (...) symbol)
# In .config after saving:
CONFIG_LOCALVERSION="-myboard-v2"
# Result on the running system:
$ uname -r
6.8.0-myboard-v2📌 Related option: CONFIG_LOCALVERSION_AUTO
When enabled, the kernel automatically appends a short git commit hash to the version
string. For example: 6.8.0-g3f5a2c1. This is very useful during active
development — every build is uniquely identified by its exact source commit. Disable it
for release/production builds where you want a clean, predictable version string.
3. CONFIG_IKCONFIG — The Config Inside the Kernel
CONFIG_IKCONFIG
Type: Tristate (y or m)
Linux 6.x: Unchanged, still in init/Kconfig
When this option is enabled, a gzip-compressed copy of the entire .config
is embedded directly inside the kernel image at build time. You can extract it later
using the scripts/extract-ikconfig script — even from a kernel image
sitting in /boot without having the original source directory.
How CONFIG_IKCONFIG Works
───────────────────────── ──────────────────────────────────┌──────────────┐ ┌────────────────────────────────┐
│ .config │ gzip compress │ vmlinuz / bzImage │
│ (your full │─────────────────────▶│ (kernel image with embedded │
│ config │ │ .config.gz section inside) │
│ choices) │ └──────────────┬─────────────────┘
└──────────────┘ │
┌─────────────┴──────────────────┐
│ Extract config from image: │
│ │
│ ./scripts/extract-ikconfig │
│ /boot/vmlinuz-6.8.0 │
│ > recovered.config │
│ │
│ Or read live via proc │
│ (needs IKCONFIG_PROC=y): │
│ │
│ zcat /proc/config.gz │
└────────────────────────────────┘USE CASE: Debug a device in the field months later. No source dir needed.
The exact config that produced this kernel is always recoverable.
⚠ Security Consideration
The embedded config reveals exactly which security features are disabled
in your kernel. On a public-facing server, an attacker who can read the kernel image
or /proc/config.gz gains a detailed map of your kernel’s weaknesses.
Most major Linux distributions disable CONFIG_IKCONFIG by default
for this reason. Enable it for development and embedded debug builds; keep it off
on hardened production systems.
4. CONFIG_IKCONFIG_PROC — Config via /proc
CONFIG_IKCONFIG_PROC
Depends on: CONFIG_IKCONFIG
Linux 6.x: Unchanged
This extends CONFIG_IKCONFIG. When both are enabled, the embedded config
is exposed through the proc filesystem as /proc/config.gz. Any user on the
running system can read it without needing the kernel image file.
# Read the running kernel's full config:
zcat /proc/config.gz | less
# Search for a specific option:
zcat /proc/config.gz | grep CONFIG_USB_SERIAL
# Example output:
CONFIG_USB_SERIAL=m
# CONFIG_USB_SERIAL_CONSOLE is not set
CONFIG_USB_SERIAL_GENERIC=y📌 Linux 6.x Note — When You Actually Need This
On most modern desktop distributions (Ubuntu, Fedora, Arch), the kernel config is
already placed at /boot/config-$(uname -r) during installation, so you
may never need CONFIG_IKCONFIG_PROC on a standard desktop. However, for
embedded products where there is no /boot partition, the filesystem is
read-only, or you are debugging remotely over SSH with no easy file access,
/proc/config.gz is invaluable — it is always up to date and needs no
filesystem changes to read.
5. CONFIG_PROFILING — Kernel Performance Analysis
CONFIG_PROFILING
Type: Boolean
Linux 6.x: Unchanged — default y in generic configs
This option enables the infrastructure that performance analysis tools plug into.
With it enabled, tools like perf, OProfile, and gprof can measure
how long the CPU spends in different kernel functions — helping you find bottlenecks
and optimise system performance.
CONFIG_PROFILING — When to Enable or Disable
────────────────────────────────── ──────────────────────────────────
✓ Performance engineering work ✗ Minimal embedded system where
✓ Using perf stat / perf record every KB of kernel size matters
✓ Server kernel tuning ✗ Safety-critical or real-time
✓ Finding kernel bottlenecks systems where extra hooks add
✓ Driver development (measuring unwanted overhead
interrupt latency etc.) ✗ Learning builds where you want
the smallest possible kernelLinux 6.x: The profiling subsystem now also serves eBPF tracing tools
(bpftrace, BCC). If you use any eBPF-based observability tools,
keep this enabled.
6. CONFIG_HAMRADIO — Auditing Unused Features
CONFIG_HAMRADIO
Type: Boolean
Linux 6.x: Still present, default y in generic configs
Amateur (HAM) radio operators use specialised transceivers that can connect to a Linux
system. The kernel includes a full networking layer and several device drivers for this
hardware. For the vast majority of Linux systems — servers, embedded devices, developer
laptops — this feature will never be used.
This option is a teaching moment, not just a checkbox. The Linux
kernel is a general-purpose project — its default configurations must support a wide
range of hardware. Features like CONFIG_HAMRADIO are ON by default
because the kernel developers cannot know whether your system will need it.
You are the one who knows. When building a custom kernel — especially for
an embedded product — systematically audit every enabled feature and ask:
will this system ever use this?
💡 The Minimal Kernel Mindset for Embedded
Every feature you leave enabled adds compiled code, attack surface, and potential
bugs. Professional embedded kernel developers routinely start from
make allnoconfig (everything off) or make localmodconfig
(only modules currently loaded on a reference board) and then enable only what the
specific product actually needs. This is called kernel hardening through
minimal configuration.
7. CONFIG_VBOXGUEST — Smart Use of Modules
CONFIG_VBOXGUEST
Type: Tristate
Linux 6.x: Present, works with VirtualBox 7.x
When Linux runs inside a VirtualBox virtual machine, the VirtualBox Guest Additions
provide host-guest integration: shared folders, shared clipboard, automatic screen
resizing, and seamless pointer integration. CONFIG_VBOXGUEST is the
kernel driver that makes all of this possible.
CONFIG_VBOXGUEST — Choosing the Right Setting
│
┌───────────┴───────────┐
│ │
Only inside On real
VirtualBox hardware
(dev VM) OR both
│ │
▼ ▼
Set to: m (MODULE) Set to: n (OFF)Why m and not y?
────────────────────────────────────────────────────────────────────────
Setting to y (built-in) means the VirtualBox driver is ALWAYS in the
kernel — even when booting on real hardware where VirtualBox does not
exist. It consumes memory, may probe hardware unnecessarily, and adds
code that will never do anything useful outside a VM.Setting to m (module) means the .ko file exists on disk but is only
loaded when the kernel detects it is running inside VirtualBox (udev
reads DMI/ACPI tables and loads the right module automatically).
On real hardware: module never loads. In VirtualBox: loads silently.This is the correct use of the module system — presence without penalty.
8. CONFIG_UIO — Userspace I/O for Embedded Developers
CONFIG_UIO / CONFIG_UIO_PDRV_GENIRQ
Type: Tristate
Linux 6.x: Unchanged, widely used in DPDK and embedded
UIO (Userspace I/O) is a framework that lets you write most of a hardware device driver
in userspace instead of as a kernel module. A very thin kernel piece handles only the
two things that must be in the kernel — interrupt handling and memory mapping
of hardware registers. Everything else — your protocol logic, state machines, data
processing — lives in a regular user-space process.
Traditional Kernel Driver vs UIO Driver Architecture
─────────────────────────────────── ─────────────────────────────────────┌───────────────────────────────┐ ┌───────────────────────────────────┐
│ User Application │ │ User Application + Device Logic │
│ (open/read/write /dev/xxx) │ │ (reads/writes /dev/uioX, │
└──────────────┬────────────────┘ │ handles all protocol logic, │
│ syscall │ state machines, data parsing) │
┌──────────────▼────────────────┐ └──────────────────┬────────────────┘
│ Kernel Driver │ │ mmap + read
│ (all logic in kernel space: │ ┌──────────────────▼────────────────┐
│ IRQ, DMA, protocol, state) │ │ Thin UIO Kernel Module │
└──────────────┬────────────────┘ │ (ONLY: interrupt handling, │
│ hardware access │ memory-mapping hardware regs, │
┌──────────────▼────────────────┐ │ exposing /dev/uioX to userspace)│
│ Hardware │ └──────────────────┬────────────────┘
└───────────────────────────────┘ │ hardware access
┌──────────────────▼────────────────┐
│ Hardware │
└────────────────────────────────────┘TRADITIONAL DRIVER — PROS: UIO DRIVER — PROS:
• Lowest possible latency • Bugs crash process, not kernel
• Tight hardware integration • No kernel recompile to update logic
• Easier to develop and debug
TRADITIONAL DRIVER — CONS: • Used by DPDK (high-speed networking)
• A bug crashes the whole system • Popular in FPGA interface drivers
• Requires kernel recompile for • Used by CONFIG_UIO_PDRV_GENIRQ for
every logic change platform devices with Device Tree
CONFIG_UIO_PDRV_GENIRQ is a specific ready-made UIO driver for
platform devices (hardware described in the Device Tree, common in ARM SoCs). Instead
of writing your own interrupt kernel module, you register your device in the Device
Tree with compatible = "generic-uio", load this module, and handle all
your device logic in userspace. Very popular in industrial embedded Linux work.
9. CONFIG_MSDOS_FS — Filesystem Driver Choices
CONFIG_MSDOS_FS
Type: Tristate
Linux 6.x: Still present for legacy FAT12 support
This enables support for the original MS-DOS FAT12 filesystem — the format used on
very early floppy disks and some legacy embedded storage media from the 1980s and
1990s. This is different from FAT32 (CONFIG_VFAT_FS), which is
what modern SD cards, USB drives, and Windows-shared storage actually use.
FAT Filesystem Options — Which Do You Actually Need?
──────────────────────────────────────────────────────────────────────────CONFIG_MSDOS_FS FAT12 Legacy floppy disks, very old media.
Most embedded projects: set to n.CONFIG_FAT_FS FAT16 Older hard disk partitions.
(base) Required by both VFAT and MSDOS_FS.
Usually auto-selected when needed.CONFIG_VFAT_FS FAT32 + ✓ SD cards (camera cards, Pi boot)
long names ✓ USB flash drives
✓ Windows-shared storage
✓ EFI system partition (/boot/efi)
Most embedded: set to y or m.CONFIG_EXFAT_FS exFAT Large SD cards > 32GB
Modern USB drives, SDXC cards.
Available from Linux 5.7+ natively.
CONFIG_NTFS_FS NTFS Read Windows NTFS partitions.
CONFIG_NTFS3_FS NTFS3 Write-capable NTFS (Linux 5.15+)
In-tree, not a FUSE driver.
──────────────────────────────────────────────────────────────────────────
RULE: Match your filesystem drivers to the ACTUAL storage your device uses.
Unused filesystem drivers = extra code, extra attack surface.
10. CONFIG_SECURITY — Never Disable This on Real Systems
⚠ CONFIG_SECURITY — Critical Security Warning
Type: Boolean
Linux 6.x: Unchanged, default y, DO NOT disable on real systems
CONFIG_SECURITY enables the Linux Security Module (LSM)
framework. This is the kernel-level infrastructure that allows mandatory
access control (MAC) systems to plug into security-critical code paths throughout
the kernel. Without it, none of the following work:
The Linux Security Module (LSM) Ecosystem
──────────────────────────────────────────────────────────────────────────┌──────────────────────────────────────────────────────────────────────┐
│ KERNEL LSM FRAMEWORK │
│ (security hooks inserted at critical kernel points) │
│ │
│ file_open() │ mmap() │ socket_connect() │ exec() │ etc. │
└──────────────┬───────────────────────────────────────────────────────┘
│ Each hook calls the active LSM(s) to approve/deny
┌─────────┴─────────────────────────────────────┐
│ │
┌────▼────────────────┐ ┌──────────────────────▼──────────────┐
│ SELinux │ │ AppArmor │
│ (Fedora, RHEL, │ │ (Ubuntu, Debian, Snap packages) │
│ Android kernel) │ │ Profile-based, per-application │
│ Label-based MAC │ │ path-based access control │
└────────────────────┘ └─────────────────────────────────────┘
┌────────────────────┐ ┌─────────────────────────────────────┐
│ Smack │ │ TOMOYO / Yama / Lockdown │
│ (Tizen, automotive │ │ (Yama: restrict ptrace scope; │
│ Linux, some IoT) │ │ Lockdown: prevent kernel │
│ Simple MAC labels │ │ tampering even by root) │
└────────────────────┘ └─────────────────────────────────────┘IF CONFIG_SECURITY=n:
→ All LSM hooks become no-ops
→ SELinux, AppArmor, Smack, Yama, Lockdown ALL stop working
→ Kernel falls back to ONLY classic UNIX permissions (rwx)
→ A process running as root has NO additional access restrictions
→ Privilege escalation exploits become FAR more effectiveWHEN IT IS OK TO DISABLE (only):
→ Throwaway VM purely for a build/compile test
→ Practice exercise to observe the effect (document and re-enable)
→ Strictly isolated development environment with no sensitive data
11. CONFIG_DEBUG_STACK_USAGE — Catching Stack Overflows Early
CONFIG_DEBUG_STACK_USAGE
Type: Boolean
Linux 6.x: Still in same location, works the same way
Every kernel thread gets a fixed-size stack — typically 8 KB or 16 KB depending on
the architecture. If a chain of function calls uses more stack than is available,
the result is a kernel stack overflow — which leads to memory corruption or an
immediate kernel panic. This is a real concern when writing device drivers, especially
on embedded platforms with small stack sizes.
How CONFIG_DEBUG_STACK_USAGE Works
──────────────────────────────────────────────────────────────────────────WITHOUT CONFIG_DEBUG_STACK_USAGE:
┌─────────────────────────────────────────────────────────────────────┐
│ Stack memory — contents unknown at creation │
│ You have no idea how much was actually used at any point │
└─────────────────────────────────────────────────────────────────────┘
→ A driver function that uses too much stack causes silent corruption.WITH CONFIG_DEBUG_STACK_USAGE:
┌──────────────────────────────────────────────────────────────────────┐
│ KNOWN PATTERN (0x57AC6E9D) fills entire stack at task creation │
│▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓│
└──────────────────────────────────────────────────────────────────────┘After the task runs for a while, the stack looks like this:
┌──────────────────────────────────────────────────────────────────────┐
│ ACTUAL USE │▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓ UNUSED (pattern still) │
│ (overwritten)│ │
└──────────────┴────────────────────────────────────────────────────────┘
← 3200 bytes →← ──────────── 4992 bytes of headroom ─────────────────→At task exit, kernel counts remaining pattern bytes → reports usage:
“Stack used: 3200 / 8192 bytes (39%)” → You are safe.
If usage approaches 80-90% → WARNING: refactor your code.
If pattern is entirely gone → OVERFLOW already happened.
──────────────────────────────────────────────────────────────────────────
ENABLE for: All driver development and kernel module writing
DISABLE for: Final production builds (small overhead on every task switch)
# Check stack usage of kernel threads on a running debug kernel:
cat /proc/*/status | grep -A1 "Name:\|VmStk"
# Kernel messages after a thread exits (with DEBUG_STACK_USAGE=y):
dmesg | grep -i "stack"
12. Quick Reference — All 10 Options at a Glance
CONFIG Option Settings by Use Case
──────────────────────────────────────────────────────────────────────────────────────────CONFIG_LOCALVERSION Custom uname -r suffix “-dev01” “-v2prod” optionalCONFIG_IKCONFIG Embed .config in kernel y y (debug) nCONFIG_IKCONFIG_PROC Expose via /proc/config.gz y y (debug) nCONFIG_PROFILING perf/eBPF profiling hooks y n y
CONFIG_HAMRADIO Amateur radio hardware n n n
CONFIG_VBOXGUEST VirtualBox guest driver m n n
CONFIG_UIO Userspace I/O framework m m or y m
CONFIG_UIO_PDRV_GENIRQ Generic UIO platform driver m m or y m
CONFIG_MSDOS_FS FAT12 filesystem m n* n
(* use CONFIG_VFAT_FS=y for SD cards instead)
CONFIG_SECURITY LSM framework (SELinux etc) y y y (ALWAYS)
CONFIG_DEBUG_STACK_USAGE Stack overflow detection y y (debug) n
──────────────────────────────────────────────────────────────────────────────────────────
y = built-in | m = module | n = disabled
✅ Key Takeaways — Lecture 19
- Use
/in menuconfig to search by CONFIG name — fastest way to find any option CONFIG_LOCALVERSIONstamps builds — essential for embedded fleet managementCONFIG_IKCONFIGembeds config in the kernel image — great for debugging, minor security tradeoff- Optional drivers like
CONFIG_VBOXGUESTshould bem(module), noty - UIO (
CONFIG_UIO) is powerful for embedded hardware where driver logic belongs in userspace - Match filesystem drivers to actual storage — do not enable
MSDOS_FSwhen you needVFAT_FS - Never disable CONFIG_SECURITY on any real system — it removes all LSM protections
- Enable
CONFIG_DEBUG_STACK_USAGEduring driver development; disable for production
🌟 Frequently Asked Questions
What does CONFIG_IKCONFIG do in the Linux kernel?
CONFIG_IKCONFIG causes the kernel build system to embed a gzip-compressed
copy of the entire .config file inside the compiled kernel image at build
time. This means the exact configuration that produced a given kernel binary is always
recoverable — from the kernel image file itself, or from the running kernel via
/proc/config.gz if CONFIG_IKCONFIG_PROC is also enabled.
This is extremely useful for debugging deployed embedded systems where the original
build directory no longer exists.
What is the Linux Security Module (LSM) framework?
The Linux Security Module framework is a kernel architecture that inserts security
hooks at critical decision points throughout the kernel — when a process opens a file,
calls exec, creates a socket, uses mmap, and so on. Security
systems like SELinux, AppArmor, Smack, Yama, and the Lockdown LSM plug into these
hooks to enforce mandatory access control policies. Enabled by CONFIG_SECURITY=y,
disabling it removes all of these protections and leaves the system with only basic
UNIX file permissions.
What is UIO (Userspace I/O) and when should I use it?
UIO is a Linux kernel framework that allows most of a hardware device driver to live
in userspace rather than as a kernel module. A minimal kernel component handles only
interrupt routing and hardware register memory mapping, while all device logic runs
in a regular user process. Choose UIO when: you want device driver bugs to crash a
process rather than the whole kernel; you need to update driver logic without
recompiling the kernel; or you are building an FPGA interface, industrial control
device, or DPDK-based high-speed network application. The companion option
CONFIG_UIO_PDRV_GENIRQ provides a ready-made UIO driver for platform
devices described in the Device Tree.
Should I compile device drivers as built-in or as modules?
The general rule is: if a driver is required before the root filesystem is
mounted (for example, the root filesystem driver itself, or essential storage
controllers), it must be built-in (y). Everything else should be a
module (m) — modules load on demand, can be unloaded to free memory,
and do not increase the kernel image size. For embedded products, also consider
make localmodconfig, which reads which modules are currently loaded on
a reference board and automatically sets only those to m, disabling
everything else.
What does CONFIG_DEBUG_STACK_USAGE do and when should I enable it?
When enabled, the kernel fills each new task’s stack with a known bit pattern at
creation time. As the task runs and functions are called, they overwrite the stack
from the top down. When the task exits, the kernel checks how much of the original
pattern has been consumed — this tells you the peak stack usage. Enable this during
all kernel module and driver development to catch potential stack overflows before
they cause crashes. Disable it for production or performance-critical builds because
filling and checking the stack pattern adds a small but measurable overhead to every
task creation and destruction.
What is CONFIG_LOCALVERSION used for in Linux kernel builds?
CONFIG_LOCALVERSION appends a custom string to the kernel’s release
identifier — the string returned by uname -r. For example, setting it
to -myboard-v2 on a 6.8 kernel produces uname -r output
of 6.8.0-myboard-v2. This is used in embedded and custom kernel
development to uniquely identify build variants, software versions, or target hardware
configurations across a fleet of devices. The companion option
CONFIG_LOCALVERSION_AUTO appends a git commit hash automatically,
which is useful during active development.
What is the difference between CONFIG_MSDOS_FS and CONFIG_VFAT_FS?
CONFIG_MSDOS_FS enables support for the original FAT12 filesystem
used on old floppy disks and some legacy storage media. CONFIG_VFAT_FS
enables support for FAT32 with long filename support — this is what modern SD cards,
USB drives, EFI system partitions, and Windows-shared storage actually use. For
embedded Linux systems using SD card storage (such as Raspberry Pi and similar boards),
you need CONFIG_VFAT_FS=y, not CONFIG_MSDOS_FS. For
very large storage (SDXC cards over 32 GB), you may also want CONFIG_EXFAT_FS,
which has been in the mainline kernel since version 5.7.
📷 Suggested Images for This Post
- Hero / thumbnail: Terminal split — left: menuconfig with General
Setup menu open; right:uname -routput showing custom
CONFIG_LOCALVERSIONstring.
Alt: “Linux kernel menuconfig hands-on configuration tutorial” - Section 3 (IKCONFIG): Terminal showing
zcat /proc/config.gz | grep CONFIG_USBoutput on a live system.
Alt: “Reading Linux kernel config from /proc/config.gz” - Section 8 (UIO): Architecture diagram showing a custom FPGA
or sensor connected to an ARM SoC, with the UIO stack labelled — thin kernel
module at bottom, userspace app at top.
Alt: “Linux UIO driver architecture for embedded hardware” - Section 10 (CONFIG_SECURITY): Side-by-side showing
sestatusoutput with SELinux enforcing (CONFIG_SECURITY=y) vs
disabled (CONFIG_SECURITY=n).
Alt: “SELinux enforcing mode requires CONFIG_SECURITY enabled in Linux kernel” - Section 11 (Stack): Visual of a kernel thread stack bar
showing used vs unused portions with the watermark pattern.
Alt: “Linux kernel stack usage measurement with CONFIG_DEBUG_STACK_USAGE”
Lecture 19
EmbeddedPathashala — Free Embedded Systems & Linux Kernel Education — embeddedpathashala.com