Linux Device Drivers

File Operations

In the next few sections, we’ll look at the various operations a driver can perform on the devices it manages. The device is identified internally by a file structure, and the kernel uses the file_operations structure to access the driver’s functions. This design is the first evidence we’ve seen of the object-oriented design of the Linux kernel. We’ll see more evidence of object-oriented design later. The structure file_operations is a table of function pointers, defined in <linux/fs.h>. The structure struct file is going to be described next.

The fops pointer, which we’ve already seen as an argument to the register_chrdev call, points to a table of operations (open, read, and so on). Each entry in the table points to the function defined by the driver to handle the requested operation. The table can contain NULL pointers for the operations you don’t support. The exact behavior of the kernel when a NULL pointer is specified is different for each function, as the list in the next section shows.

The file_operations structure has been slowly getting bigger as new functionality is added to the kernel (although no new fields were added between 1.2.0 and 2.0.x). There should be no side effects from this increase, because the C compiler takes care of any size mismatch by zero-filling uninitialized fields in global or static struct variables. New items are added at the end of the structure,^[10] so a NULL value inserted at compile time will select the default behavior ...