Introduction to Linux Device Drivers and My Learning Journey 

Why I Started Learning Linux Drivers 

Linux device drivers enable communication between the operating system and hardware, acting as an interface between user applications and physical devices like keyboards, storage drives, and network interfaces.

A while ago, during my university Operating Systems course, I worked with character devices on an Ubuntu VM. This gave me a foundation in interacting with device drivers from user space, but I soon realized that true driver development required a deeper understanding of:

• Kernel-space programming – Writing code that interacts directly with the Linux kernel.

• Device registration and module management – Ensuring the system recognizes and loads the driver.

• User-space interaction – Enabling controlled communication between applications and hardware.

Wanting to go beyond my coursework, I explored driver development for embedded systems. I had already used my Raspberry Pi 4B for research projects, primarily with Python scripts, but I wanted to understand how hardware interacts with the kernel at a lower level. This felt similar to transitioning from Arduino’s abstraction to AVR bare metal programming or STM32 development.

Recently, I started using NixOS, further fueling my curiosity about how Linux drivers work and how they can be used in embedded applications.

This blog documents my learning journey, where I explore character, block, and procfs drivers, leading toward writing basic kernel modules that interface with Raspberry Pi 4B hardware and user-space applications. 

Prior Experience with Linux Drivers 

In my Operating Systems course, I worked with character devices on an Ubuntu VM, where I learned:

• How character devices interact with the Linux kernel.

• How to create and register a character device.

• Where to find major and minor device numbers in /dev/.

• How to compile, load, and remove kernel modules (make, insmod, rmmod).

• Using dmesg to debug driver behavior.

• Implementing file operations (read, write, ioctl) to interact with a driver.

To expand my understanding, I followed several online resources focused on Linux driver development:

• "Linux Device Drivers Development Course for Beginners" (FreeCodeBootCamp.org) – A structured introduction to kernel programming.

• YouTube @LowLevelTV Raspberry Pi Kernel Driver tutorial playlist – Covers procfs device implementation for GPIO control.

• Johannes 4GNU_Linux tutorials – Covers drivers, USB, networking/ethernet, and embedded systems in-depth.

While this provided a solid foundation, my main goal was to apply driver development to embedded systems. Instead of just compiling and running pre-existing examples, I wanted to explore how the Linux kernel interacts with hardware—specifically GPIO and serial interfaces on embedded platforms like the Raspberry Pi 4B. Understanding this would allow me to develop drivers that efficiently communicate with peripherals in a resource-constrained environment.

Building and Testing My First Character Device Driver

As part of my course, I worked with a character device driver that allowed a user-space application to:

• Read from the device buffer – Retrieve stored data.

• Write to the device buffer – Modify contents while logging changes in the kernel.

• Use ioctl to modify driver behavior – Send custom commands to control driver operations.

To test my driver, I wrote a C-based user application that:

• Used getline() to send data to the driver.

• Read the stored data from the driver buffer.

• Used ioctl to send predefined arguments (0, 1, 2) and receive different responses.

Debugging a Read Failure in My Driver

One challenge I faced was that after multiple writes, the read function stopped working. I suspected this was due to a buffer issue—either an incorrect offset or buffer overflow.

Using dmesg logs, I discovered that the read pointer wasn't resetting correctly, causing unexpected behavior. To fix this, I implemented an ioctl option to clear the static buffer using memset() and resetting the offset. This ensured that the driver maintained proper behavior even after multiple write operations.

This debugging experience helped me understand:

• How to manage buffers effectively in kernel space.

• The importance of proper state management for stability.

• How ioctl provides additional control beyond basic read/write operations.

Through testing with a user-space application, I also learned how user programs communicate with kernel modules and how kernel logs (dmesg) provide valuable debugging insights.

What’s Next? 

This post outlined my first experience with Linux driver development and how I worked with character devices on an Ubuntu VM.

Before diving into writing custom drivers, it’s important to understand some key Linux fundamentals:

• How the Linux kernel initializes hardware and loads drivers – The kernel loads built-in drivers during boot, while loadable modules (like custom drivers) can be inserted later using insmod or automatically by udev.

• Kernel Space vs. User Space – Drivers run in kernel space with full system access, while applications run in user space and communicate with drivers through system calls like read(), write(), and ioctl(). (More info) 

• Different types of Linux device drivers – Linux device drivers include character (byte stream, e.g., serial ports, GPIO), block (fixed-size blocks, e.g., HDDs, SSDs), network (packet-based, e.g., Ethernet, Wi-Fi), and pseudo-filesystem drivers (kernel data via /proc, /sys). Other types include USB, PCI, platform, and virtual drivers for various hardware interfaces. While it's important to understand these categories, I'll focus on character and procfs drivers, which are most relevant for embedded systems using GPIO, I2C, and SPI. 

With these basics in mind, the next step is writing a basic kernel module to interface with hardware.

Stay tuned!