Introduction
Synchronization bugs are among the most difficult issues to debug in kernel-space software. A simple character device driver can become unsafe when multiple processes access shared resources concurrently.
In this article, I build and analyze a Linux character device driver that demonstrates four important kernel concepts:
The driver creates a device node named:
/dev/mydevice
and returns a simple message to userspace when read.
Concept 1: Mutex Synchronization
A mutex ensures that only one execution context accesses a critical section at a time.
The driver declares a mutex using:
static DEFINE_MUTEX(dev_mutex);
Before accessing shared state, the driver acquires the lock:
if (mutex_lock_interruptible(&dev_mutex))
return -ERESTARTSYS;
and releases it when finished:
mutex_unlock(&dev_mutex);
Why Use a Mutex?
Without synchronization, multiple processes could simultaneously execute the read handler and modify shared data.
Benefits of mutexes include:
Preventing race conditions
Protecting shared kernel data
Simplifying synchronization logic
Allowing sleeping operations safely
Unlike spinlocks, mutexes can safely surround operations such as:
copy_to_user(...)
which may sleep.
Concept 2: Concurrency in Device Drivers
Concurrency occurs when multiple execution contexts attempt to access the same resource at the same time.
Consider several terminals executing:
cat /dev/mydevice
simultaneously.
Without synchronization:
Multiple threads may enter the read handler together
Shared state can become inconsistent
Race conditions become possible
With mutex protection:
Access becomes serialized
Shared state remains consistent
Device behavior becomes predictable
Kernel developers must always assume that a driver may be accessed concurrently.
Concept 3: Character Device Drivers
A character device transfers data as a stream of bytes between user space and kernel space.
Common examples include:
/dev/null
/dev/random
/dev/tty
Our module registers a character device using:
major_num = register_chrdev(
0,
"mydevice",
&fops
);
Passing zero requests a dynamically allocated major number.
File Operations Interface
The kernel communicates with the driver through a file operations table:
static const struct file_operations fops = {
.open = dev_open,
.read = dev_read,
.release = dev_release,
};
This maps standard system calls to driver callbacks.
| User Action |
Driver Function |
| open() |
dev_open() |
| read() |
dev_read() |
| close() |
dev_release() |
Safe User-Space Communication
Kernel memory cannot be accessed directly from user space.
Instead, Linux provides helper APIs such as:
copy_to_user(buf, msg_data, len);
This function:
Validates user-space addresses
Handles page faults safely
Prevents invalid memory access
It is the standard mechanism for transferring data from kernel space to user space.
Read-Once Device Behavior
The driver implements a simple read-once mechanism.
The key logic is:
if (*ppos > 0)
return 0;
After the first successful read:
This pattern is commonly used in educational and demonstration drivers.
Concept 4: Linux Version Compatibility
Kernel APIs evolve over time.
A driver that compiles on one kernel version may fail on another if APIs change.
To support multiple kernels, the module uses:
#if LINUX_VERSION_CODE >= KERNEL_VERSION(6,4,0)
For newer kernels:
class_create("mydevice_class");
For older kernels:
class_create(
THIS_MODULE,
"mydevice_class"
);
This allows a single codebase to compile across multiple Linux releases.
Important Kernel APIs
| API |
Purpose |
| register_chrdev() |
Register character device |
| unregister_chrdev() |
Remove character device |
| class_create() |
Create device class |
| device_create() |
Create device node |
| copy_to_user() |
Transfer data to user space |
| DEFINE_MUTEX() |
Declare mutex |
| mutex_lock_interruptible() |
Acquire mutex |
| mutex_unlock() |
Release mutex |
What This Project Demonstrates
This small module covers several important kernel-development concepts:
Character device registration
Dynamic device creation
User-space interaction
Mutex-based synchronization
Concurrency protection
Read-once semantics
Cross-version kernel compatibility
Although simple, these concepts appear repeatedly in production Linux drivers.
Conclusion
Character device drivers provide an excellent introduction to Linux kernel development. Even a small driver can expose important topics such as synchronization, concurrency, memory safety, and API compatibility.
By combining mutex protection with a clean character-device interface, this example demonstrates how Linux drivers safely interact with user-space applications while maintaining correctness under concurrent access.
Source Code
GitHub Repository: 👉 linux_kernel_con_c_1 Explore the complete source code, build files, and module implementation on GitHub.
