How Linux system calls interact with the kernel or the underlying driver

Learning the Linux system Driver development has been a large half a year, the mind has been a doubt: that is, such as open, write, read and other system calls is how and
is the kernel or the underlying driver connected? Today, we summarize some of my own rough understandings as follows.

Having learned about driver development under Linux, most of the basic drive operations include 3 important kernel data structures, called file_operations,
file, and Inode. We need a basic understanding of these structures to be able to do a lot of interesting things.

1, struct file_operations is a character device-driven operation and device number linked together, is a collection of pointers, each open file
Corresponds to a series of operations, which is file_operations, which is used to perform a series of system calls.

2. The struct file represents an open file that is created when the open operation in File_operation is performed, and it is important to note that the area of the Inode pointer with the user space
No, one is in the kernel, and the file pointer is in user space, defined by the C library.
3, the struct inode is used by the kernel to represent a file, note and struct file differences, struct inode is a representative file, struct file is a file that represents the open
The struct inode consists of a very important two members:
dev_t the device number of the I_rdev device file
struct Cdev *i_cdev represents the data structure of the character device, and the struct inode structure is used to represent the file within the kernel. The same file can be opened a lot
can correspond to many struct file, but only one struct inode.

        the application layer calls the Open function, it first issues an open system call, then enters the   kernel, calls the Sys_open function, Open the file system/dev/fs file, this file either
you are built with Mknod, or directly in the kernel with DEVFS way to build, no matter how you build, eventually will read its file attributes, if found to be a device
file, The Device Management section of the Linux kernel is called, depending on the main device number of its properties (the main device number is written to the file attribute when the device node is established, if you have carefully
seen Mknod's usage), find the associated file_operations in the kernel, Finally, find your Test_open function.
        so   "device in Linux is File  ", the device driver first goes to the file system, such as the first   "/dev /fs  "), and then, depending on the properties of the device file, finally find the
to the associated file_operations, which calls your device driver routine. If you find this file is not a device file but a disk file, continue to file system, cache
With disk scheduling this way.

 
        sys_open (kernel function) directly to the VFS layer, In the open process will get the inode of the device file (by passing in the filename parameter), (refer to my It
about the inode introduction), its file_operations structure is assigned to the file structure (including this member FoPs) the corresponding member, And when the open method is not used for air conditioning. However, special file
in the inode of the file_operations are the same, such as the character device file Inode file_operations only defined an open method, the open method according to the device in the Inode
The Cdev is found in the registered character device driver, and the FoPs in this cdev is provided by the driver. It is assigned to the corresponding member (file_operations struct)
in the file struct (overwriting the previous assignment), and its open method is called without being empty.

Now let's demonstrate how the user writes data to the device using the Write function:  
    1,insmod driver. The driver requests the device name and the main device number, which can be obtained in/proc/devieces.  
    2, obtain the main device number from/proc/devices, and use the Mknod command to establish the device node file. This is the device node file and device driver that is associated with the
with the main device number. The function pointers implemented by the FoPs method in the driver are indicated in the file property in the device node files.  
    3, the user program opens the device node file using open, and the operating system kernel knows that the driver is working, and calls the Open function in the FoPs method to work accordingly. The
Open method typically returns a file identifier that is not actually manipulated directly, but rather by the system call of the operating system behind it.  
    4, when the user uses the Write function to manipulate a device file, the operating system calls the Sys_write function, which first obtains the Inode pointer for the device node file by using the file identifier
and the flip pointer. The inode pointer has the device number information that tells the operating system which device driver to use, and the flip pointer has fops information that tells the operating system that the corresponding
FoPs method function can be found there.  
    5, and then Sys_write calls the Write method in the driver to do the writing to the device.  

     1-3 of them are in user space and 4-5 in the core space. The write function of the user and the write function of the operating system are associated with the system call Sys_write.  
     Note:

In general: Device files are bundled with device drivers through the device number, and FoPs binds the write and drive layer of the application layer. When the application layer writes a device file, the system
Find the corresponding device driver, and then find the corresponding drive write function through FoPs.

int open (const char *pathname, int flags, mode_t mode); --System call
||
\/
Long Sys_open (const char __user *filename, int flags, int mode)--FS/OPEN.C
/* The Open Interface function in the corresponding kernel */
||
\/
Long Do_sys_open (int dfd, const char __user *filename, int flags, int mode)--FS/OPEN.C
/* The filename of the user space is copied to the kernel space to obtain the currently available file descriptor */
||
\/
static struct file *do_filp_open (int dfd, const char *filename, int flags, int mode)--FS/OPEN.C
||
\/
int Open_namei (int dfd, const char *pathname, int flag,
int mode, struct nameidata *nd)
/* Get the NAMEIDATA structure for the file. The function is finished, and then the following function is called. These two functions are called sequentially by Do_filp_open */
||
\/
struct file *nameidata_to_filp (struct nameidata *nd, int flags)--FS/OPEN.C
/* Convert the NAMEIDATA structure to an open struct file structure */
||
\/
static struct file *__dentry_open (struct dentry *dentry, struct vfsmount *mnt,
int flags, struct file *f,
Int (*open) (struct inode *, struct file *))--FS/OPEN.C
||
\/
F->f_op = Fops_get (INODE->I_FOP); --fs/open.c
/* Here the system calls need to correspond to open files corresponding to the kernel of the file_operations structure obtained, and then according to its function pointer can be found in the structure of the
All methods for this kind of file operation. The scull corresponding structure is registered with the kernel at the time of Scull_init.
||
\/
Open = f->f_op->open;
Open (Inode, f); --fs/open.c
/* The above two lines of code completed the open system call when executing the actual file corresponding to the open method of the kernel, namely Scull_open.

How Linux system calls interact with the kernel or the underlying driver