Linux kernel Source-code scenario analysis-Virtual file system

Let's look at two graphs first:

The first is the relationship between VFS and the specific file system:

The second is the hierarchical structure of the Linux file system:

Special files: Files used to implement "pipes", especially FIFO files for "Named Pipes", and sockets for UNIX domains, also belong to special files, and a series of files in the/proc directory.

Disk File: The file that exists on the hard disk.

Device files: sudo mount-t ext2/dev/sdb1/mnt/sdb, where/DEV/SDB1 is the device file. If the node on the hard disk is Raw_inode->i_block[block], if you get the inode for the directory node, then i_block[] stores the location of the catalog item. If it is the inode of the file node, then i_block[] stores the location of the real data, and now the inode of the device node stores the device number (including the main device number and the secondary device number).

The difference between their code is as follows, the Ext2_read_inode code is as follows:

if (inode-    >i_ino = = Ext2_acl_idx_ino | | Inode->i_ino = = Ext2_acl_data_ino)/* Nothing to do * *, else if (S_isreg (Inode->i_mode)) {//HDD file, normal file Inode->i_op = &ext2_file_inode_operations;inode->i_fop = &ext2_file_operations;inode->i_mapping->a_ops = & Ext2_aops;} else if (S_isdir (Inode->i_mode)) {//hard disk file, directory file Inode->i_op = &ext2_dir_inode_operations;inode->i_fop = &ext2_dir_operations;} else if (S_islnk (Inode->i_mode)) {//hard disk file, link file if (!inode->i_blocks) Inode->i_op = &ext2_fast_symlink_ inode_operations;else {inode->i_op = &page_symlink_inode_operations;inode->i_mapping->a_ops = & Ext2_aops;}} else Init_special_inode (Inode, Inode->i_mode, Le32_to_cpu (raw_inode->i_block[0])); 

void Init_special_inode (struct inode *inode, umode_t mode, int rdev) {Inode->i_mode = Mode;if (S_ISCHR (mode)) {//device file, Word Symbol device INODE->I_FOP = &def_chr_fops;inode->i_rdev = to_kdev_t (Rdev);} else if (s_isblk (mode)) {///device file, block device Inode->i_fop = &def_blk_fops;inode->i_rdev = to_kdev_t (Rdev); inode->i _bdev = Bdget (Rdev);} else if (S_isfifo (mode))//special file, named pipe INODE->I_FOP = &def_fifo_fops;else if (s_issock (mode))//special file, Socket file Inode->i_fop = &BAD_SOCK_FOPS;ELSEPRINTK (kern_debug "Init_special_inode:bogus imode (%o) \ n", mode);}

First, we compare the open to special files, named pipes and hard disk files, ordinary files to do the comparison.

For special files, refer to the Linux kernel source scenario analysis-interprocess communication-Named pipes for the opening of the named pipes.

For hard disk files, please refer to the Linux kernel source code scenario analysis-Open the file. F->f_op has pointed to the ext2_file_operations.

The difference is that when Dentry_open () is F->f_op->open, the normal file points to Ext2_open_file, and the named pipe points to Fifo_open.

F->f_op = Fops_get (INODE->I_FOP);//f->f_op is assigned Inode_i_fop    if (INODE->I_SB)        file_move (F, & Inode->i_sb->s_files),//The file structure queue S_files    if (f->f_op && f) in the super_block structure of the device to which it is being removed from the intermediate queue >f_op->open) {        error = F->f_op->open (inode,f);//normal file points to ext2_open_file, while named Pipes point to Fifo_open        if ( Error)            goto Cleanup_all;    }   

In addition, the process of calling Path_walk in open also differs depending on the code executed by Dentry->d_op and Inode->i_op.

Second, the comparison between the reading of ordinary files and the reading of pipeline files.

Read the normal file, read maps to the kernel is Sys_read, the code is as follows:

Asmlinkage ssize_t sys_read (unsigned int fd, char * buf, size_t count) {ssize_t ret;struct file * File;ret =-ebadf;file = Fget (FD); if (file) {if (File->f_mode & fmode_read) {ret = Locks_verify_area (Flock_verify_read, file->f_ Dentry->d_inode,file, File->f_pos, Count), if (!ret) {ssize_t (*read) (struct file *, char *, size_t, loff_t *); ret = -einval;if (file->f_op && (read = file->f_op->read)! = NULL) ret = read (file, buf, Count, &file->f_ POS);//generic_file_read}}if (Ret > 0) inode_dir_notify (file->f_dentry->d_parent->d_inode,dn_access); Fput (file);} return ret;}

For hard disk files, please refer to the Linux kernel source code scenario analysis-Open the file. F->f_op has pointed to the ext2_file_operations. So file->f_op->read points to generic_file_read.

For a pipeline file, refer to the Linux kernel source scenario analysis-interprocess communication-pipelines. F->f_op points to Pipe_read.

The pointer s_op in the SUPER_BLOCK structure of different file system points to the specific super_operations data structure.

Refer to Linux kernel source code scenario analysis-Get_new_inode related code from pathname to target node:

static struct Inode * Get_new_inode (struct super_block *sb, unsigned long ino, struct list_head *head, find_inode_t find_a ctor, void *opaque) {struct Inode * Inode;inode = Alloc_inode (); if (inode) {struct inode * Old;spin_lock (&inode_lock); * We released the lock, so. */old = Find_inode (SB, Ino, head, find_actor, opaque);//Once again in the hash table queue looking for if (!old) {//If not found Inodes_stat.nr_inodes++;list_ Add (&inode->i_list, &inode_in_use); List_add (&inode->i_hash, head);//Add to the corresponding hash table INODE->I_SB = SB;//Super block structure Inode->i_dev = sb->s_dev;//device number Inode->i_ino = ino;//node Number inode->i_flags = 0;atomic_set (& Inode->i_count, 1); inode->i_state = I_lock;spin_unlock (&inode_lock); Clean_inode (inode);sb->s_op->  Read_inode (inode);//Depending on the file system, point to different code/* * This is special!  We don't need the spinlock * when clearing i_lock, because we ' re guaranteed * This nobody else tries to does anything about The * State of the inode when it was locked, as we * just created it (so there can are no old Holders * that haven ' t tested I_lock). */inode->i_state &= ~i_lock;wake_up (&inode->i_wait); return inode;} /* * Uhhuh, somebody else created the same inode under * us. Use the old inode instead of the one we just * allocated. */__iget (old),//If the inode structure Spin_unlock (&inode_lock);d Estroy_inode (inode) is found, Inode = old;//uses the inode structure found Wait_on_ Inode (inode);} return inode;}

Sb->s_op->read_inode (inode);//point to different code depending on the file system.

Summarize:

We liken the filesystem to the "interface card" and the virtual file system VFS to a slot. Therefore, the pointer f_op in the file structure can be considered as a contact in the socket, and there are similar contacts in the Dentry, inode, super_operations data structures.

We saw it in the above. The main differences are as follows:

File operation Jump table, that is, file_operations data structure: Pointer f_op in the file structure points to the specific file_operations structure, which is a jump table for file operations such as open (), read (), write (), and so on. A file system is not limited to a file_operations structure, such as ext2, there are two such data structures, respectively, for ordinary files and directory files.

Directory Entry Operations Jump table: that is, dentry_operations data structure: dentry structure of the pointer D_op point to the specific dentry_operations data structure, which is the kernel of the hash (), compare () and other internal operations of the jump table.

The index node operates the jump table, the inode_operations data structure, and the pointer i_op in the INODE structure points to the specific inode_operations data structure, lookup (), permissions (), and other internal functions of the jump table.

The Super block operation Jump table, the SUPER_OPERATIONS data structure: pointer s_op in the SUPER_BLOCK structure points to the specific super_operations data structure, which is Read_inode (), Write_inode (), Delete_inode () such as a jump table for internal operations.

Linux kernel Source-code scenario analysis-Virtual file system