File structure

struct file, defined in <linux/fs.h>, is the second most important data structure in the device driver. Note that file has nothing to do with the FILE pointer of the user space program. A FILE is defined in the C library and never appears in the kernel code. A struct file, on the other hand, is a kernel structure that never appears in the user program.

The file structure represents an open file. (It is not specific to device drivers; each open file in the system has an associated structfile in kernel space). It is created by the kernel at open and passed to any function that operates on the file until the last close. After all instances of the file are closed, the kernel releases the data structure.

In kernel source code, pointers to struct files are often referred to as file or filp("file pointer"). We will always call this pointer filp to avoid confusion with the structure itself. Therefore, file refers to the structure, and filp is the structure pointer.

The most important members of the struct file are shown here.

1.mode_t f_mode;

File mode determines whether the file is readable or writable (or both), via bits FMODE_READ and FMODE_WRITE. You may want to be in your open or The ioctl function checks the read and write permissions of this member, but does not need to check the read and write permissions, because the kernel checks before calling your method. The attempt to read or write is rejected when the file has not been opened for that kind of access, and the driver does not even know about this.

2.loff_t f_pos;

Current read and write position. Loff_t is 64 bits on all platforms (long long in gcc terminology). The driver can read this value if it needs to know the current position in the file, but it should not normally change it; read and write should use the pointer they received as the last parameter to update a position instead of acting directly on filp-> ;f_pos. An exception to this rule is in the llseek method, which is designed to change the file location.

3.unsigned int f_flags;

These are file flags, such as O_RDONLY, O_NONBLOCK, and O_SYNC. The driver should check the O_NONBLOCK flag to see if it is requesting a non-blocking operation; other flags are rarely used . In particular, read/write permissions should be checked, using f_mode instead of f_flags. All flags are defined in the header file <linux/fcntl.h>.

4.struct file_operations *f_op;

Operations associated with files. The kernel arranges the pointer as part of its open implementation, and then reads it when it needs to dispatch any operations. The value in filp->f_op is never saved as a back reference by the kernel; this means you can change the file operations associated with your file, and the new method will work after you return to the caller. For example, the open code associated with major number 1 (/dev/null, /dev/zero, etc.) replaces the operation in filp->f_op based on the open minor number. This approach allows several behaviors to be implemented under the same major number without having to introduce overhead into each system call. The ability to replace file operations is a kernel peer for

object programming "method overloading".

5.void *private_data;

The open system call sets this pointer to NULL before calling the open method for the driver. You are free to use this member or ignore it; you can use this member to point to the allocated data, but then you must remember to free that memory in the release method before the kernel destroys the file structure. Private_data is a useful resource that preserves state information between system calls, which we use in most of our example modules.

6.struct dentry *f_dentry;

The directory entry (dentry) structure associated with the file. Device driver writers do not normally need to care about the dentry structure, except that they access the inode structure as filp->f_dentry->d_inode.

There are several members of the real structure, but they are not useful for device drivers. We can safely ignore these members because the drivers never create file structures; they actually access structures created elsewhere.