In this lesson, you will learn how to bridge the gap between user-space system calls and your custom kernel module by implementing the file_operations structure.
When a user process executes open(), read(), or write() on a character device file (like /dev/my_device), the kernel doesn't automatically know how to handle these requests. Instead, it looks up the file’s associated inode and finds a pointer to a struct file_operations structure provided by your driver. This structure is essentially a map of function pointers that tells the kernel, "When the user calls read(), execute this specific C function in my driver."
Defining the Operations
To implement this, you must first define your functions and then assign them to the structure. The kernel expects these functions to follow a specific signature. For example, if you want to allow users to read data from your hardware buffer, you define a read function:
static ssize_t my_driver_read(struct file *file, char __user *buf, size_t count, loff_t *ppos) {
// 1. Fetch data from your hardware/buffer
// 2. Use copy_to_user() to safely send it to the user-space buffer
// 3. Return the number of bytes read
return bytes_read;
}
static struct file_operations my_fops = {
.owner = THIS_MODULE,
.read = my_driver_read,
.write = my_driver_write,
.open = my_driver_open,
};
Mapping the Operations
Once your file_operations structure is defined, you need to register it with the kernel. This is typically done during the module initialization phase when you register your character device. By passing the address of my_fops to the kernel registration functions, you complete the mapping.
When a process initiates a system call, the kernel uses the file descriptor to find your device, looks at the file_operations map, and jumps directly to the function address you provided. This mechanism is the foundation of the Unix philosophy "everything is a file," allowing user applications to interact with complex embedded hardware using the exact same standard interface they use for simple text files.
Key Takeaway: The file_operations structure acts as a jump table that connects standard POSIX system calls to your custom driver logic, enabling a seamless interface between user-space applications and hardware registers.