3. File, Inode structure and Chardevs array and other related knowledge analysis

50850004
Describes the function call relationships between virtual file systems in Linux, generic device files and device drivers

shows an application calling character device driven process, in the device driver design, in general, the relationship between the file and the Inode two structures.
User space using the open () function opens a character device FD = open ("/dev/hello", o_read); This function calls two data structure struct inode{}&struct file{}. Both are located in the virtual file system VFS, These two data structures are parsed as follows:
1. File structure
(1) This is a very important data structure in the device driver.
(2) The file in this case is different from the file pointer in the user space, the user space file is defined in the C library and never appears in the kernel. The struct file is the data structure in the kernel, so it does not appear in the user-level program.
(3) The file structure indicates an open document (device corresponding device file), in fact, each open file in the system has a corresponding struct file structure in the kernel space, which is created by the kernel when the file is opened and passed to any function on the process operation on the file until the file is closed. If the file is closed, the kernel releases the corresponding data structure.
(4) in the kernel source code, the struct file is either represented as file, or Filp (meaning "file pointer"), note that the file refers to the struct file itself, and FILP is a pointer to the struct body.
Here are a few important members
A--fmode_t f_mode;
This file mode is Fmode_read, Fmode_write identifies the file as readable, writable, or both. In the open or IOCTL function, you may need to check this field to confirm the read/write permission of the file, you do not have to directly detect read or write permissions, because the kernel itself needs to detect the permissions when doing OCTL operations.
B--loff_t f_pos;
The location of the current read and write file. is 64 bits. If you want to know where the current file is located, the driver can read the value without changing its position. For Read,write, when it receives a loff_t pointer as its last parameter, their read and write operations update the location of the file without the need to perform the FILP->f_pos operation directly. The purpose of the Llseek method is to change the location of the file.
C--unsigned int f_flags;
File flags, such as O_rdonly, O_nonblock, and O_sync. You can also check the O_NONBLOCK flag in the driver to see if there are non-blocking requests. Other signs are less used. It is particularly important to note that read and Write permissions are checked using F_mode instead of F_flog. All scalar definitions in the header file
D--struct file_operations *f_op;
Various actions related to the file. When a file needs to perform various operations quickly, the kernel assigns this pointer as part of its implementation of file opening, reading, and writing functions. Filp->f_op its value has never been saved by the kernel as the next reference, which means you can change the various actions associated with the file, which is very efficient.

e--void *private_data;
The open system call sets this pointer to a null value before the drive calls the open method. You can be free to make it your own data domain or whatever it is, such as you can point to a well-allocated data, but you must remember to release the memory space of the data in the release method before the file struct is destroyed by the kernel. Private_data is useful for saving various state information during a system call.

/*********************************/

3. File, Inode structure and Chardevs array and other related knowledge analysis