Article Title: Resolve the VFS file system mechanism in Linux (below ). Linux is a technology channel of the IT lab in China. Includes basic categories such as desktop applications, Linux system management, kernel research, embedded systems, and open source.
5. Create a directory under VFS
To better understand VFS, let's take a practical example to see how Linux creates a new "/dev" directory under the root directory of VFS.
To create a new directory in VFS, you must first search for the directory to find information about its parent directory, ". For example, to create a directory/home/ricard, you must first perform a layer-by-layer search along the directory path. In this example, you must first find the directory from the root directory and then find the directory home under the root directory, next, you need to create a new directory named ricard. First, you need to search for the directory. In this example, you need to find the parent directory of the new directory ricard, that is, the information corresponding to the home directory.
Of course, if an error is found during the search process, for example, the parent directory of the directory to be created does not exist, or the current process does not have the corresponding permissions, the system will call the relevant process for processing in this case, in this case, I will not mention it.
In Linux, sys_mkdir is called by the system to add new nodes to the VFS directory tree. In addition, the following data structure is introduced for collaborative path search:
Struct nameidata {
Struct dentry * dentry;
Struct vfsmount * mnt;
Struct qstr last;
Unsigned int flags;
Int last_type;
};
This data structure is used to record relevant information in the path search process and plays a similar role as a "road map. The dentry in the first two items records the information of the parent directory of the directory to be created. The mnt member will explain it later. The last three records are the information of the last node (that is, the directory or file to be created) of the path to be searched. Currently, sys_mkdir ("/dev", 0700) is called to create the directory "/dev". The parameter 0700 is ignored. It only limits the mode of the directory to be created. The sys_mkdir function first calls path_lookup ("/dev", LOOKUP_PARENT, & nd); to find the path, where nd is the variable declared by struct nameidata nd. In the subsequent description, because the function call relationship is cumbersome, in order to highlight the main process line, it will not be described strictly according to the function call relationship.
Path_lookup finds that "/dev" starts with "/", so it looks down from the root directory of the current process. The specific code is as follows:
Nd-> mnt = mntget (current-> fs-> rootmnt );
Nd-> dentry = dget (current-> fs-> root );
Remember to record the newly created VFS root directory information in the init_task process data block in the second half of the init_mount_tree () function. In this scenario, nd-> mnt points to the mnt variable in Figure 3, AND nd-> dentry points to the dentry variable in figure 3.
Then, call the path_walk function and go down to find the information returned by the nd variable. last. name = "dev", nd. last. len = 3, nd. last_type = LAST_NORM. For the mnt and dentry members in nd, the value set previously remains unchanged in this scenario. In this loop, we only use nd to record the relevant information. The actual Directory creation work is not really expanded, but the previous work has collected the necessary information for creating new nodes.
Well, the creation of a new directory node will be expanded so far. This is done by the lookup_create function. When calling this function, two parameters will be passed in: lookup_create (& nd, 1 ); the nd parameter is the variable mentioned above. Parameter 1 indicates creating a new directory.
The general process here is: a new memory space with a struct dentry structure is allocated to record the information corresponding to the dev directory. The dentry structure will be mounted to its parent directory, that is, in the dentry structure corresponding to the "/" directory in Figure 3, this relationship is implemented by the linked list. Next we will assign a struct inode structure. The I _sb in Inode AND THE d_sb in dentry point to the sb in Figure 3 respectively. In this way, when creating a new directory in the same file system, you do not need to re-allocate a super block structure, because they all belong to the same file system, a file system corresponds to only one super block.
In this way, after sys_mkdir is called to successfully create a new directory "/dev" in the VFS directory tree, the relationship between the new data structures is shown in figure 3. In Figure 4, The two rectangular blocks new_inode and new_entry are the newly allocated memory structures in the sys_mkdir () function. For the mnt, sb, dentry, inode, and other structures in the figure, the data structure in Figure 3 remains unchanged. (to avoid excessive link curves, some links, such as mnt and sb, are ignored, dentry links. You can refer to figure 4 on the basis of Figure 3 ).
It should be emphasized that, since the rootfs file system is mounted to the VFS tree, it will inevitably participate in the sys_mkdir process. In fact, throughout the process, ramfs_mkdir, ramfs_lookup, and other functions in the rootfs file system have been called.
Figure 4: Create a new directory "dev" in the VFS tree"
6. Mount the file system in the VFS tree
This section describes how to mount a file system to a directory (mount point) in the directory tree of VFS.
This process can be simply described as: Install a file system (file_system_type) on a certain device (dev_name) to a directory (dir_name) on the VFS directory tree ). The solution is to convert operations on a directory in the VFS directory tree to operations on the actual file system installed on it. For example, if you install the root file system on hda2 (assuming the file system type is ext2) to the "/dev" directory created in the previous section (at this time, the "/dev" directory becomes the Installation Point). After the installation is successful, you must execute the "ls" command to the "/dev" directory of the VFS file system, this command should be able to list all directories and files under the root directory of the ext2 File System on hda2. Obviously, the key here is how to convert the "/dev" directory operation commands in the VFS tree to the corresponding commands in the ext2 actual file system installed on it. Therefore, the next statement will focus on how to transform this core issue. Before proceeding, you may wish to imagine how the Linux system will solve this problem. Remember: operations on directories or files will eventually be performed by the corresponding functions in the I _op and I _fop function tables in the inode structure corresponding to the directory or file. Therefore, no matter what the final solution is, you can imagine that I _op and I _fop in the inode corresponding to the "/dev" directory must be converted to I _op and I _fop IN THE inode corresponding to the root file system ext2 in hda2..
The initial process is initiated by the sys_mount () system calling function. The prototype declaration of this function is as follows:
Asmlinkage long sys_mount (char * dev_name, char * dir_name, char * type,
Unsigned long flags, void * data );
The char * type parameter indicates the file system type string to be installed, which is "ext2" for the ext2 file system ". The flags parameter is the number of pattern identifiers during installation, which is the same as the following data parameter. This document does not focus on it.
To help readers better understand this process, I will use a specific example to describe how to prepare a 2nd partition (hda2) for the self-owned hard disk in the future) the ext2 File System on is installed in the "/dev" directory created earlier. The call to the sys_mount () function is as follows:
Sys_mount ("hda2", "/dev", "ext2 ",...);
After copying these parameters from the user's memory space to the kernel space, the function calls the do_mount () function to install the file system. Similarly, in order to easily describe and clarify the main process, the subsequent instructions will not strictly follow the specific function call details.
The do_mount () function first calls the path_lookup () function to obtain information about the Installation Point, as described during Directory Creation, the information of this installation point is recorded in a variable of the struct nameidata type. For the convenience of description, the variable is recorded as nd. In this example, when the path_lookup () function returns, the following information is recorded in the nd: nd. entry = new_entry; nd. mnt = mnt; variables 3 and 4 are shown here.
The do_mount () function then calls one of the following four functions based on the call parameter flags: do_remount (), do_loopback (), do_move_mount (), and do_add_mount ().
In our current example, the system will call the do_add_mount () function to install an actual File System in the VFS Tree "/dev. In do_add_mount (), two important tasks are completed: obtain a new installation area block, and add the new installation area block to the installation system linked list. They are completed by calling the do_kern_mount () and graft_tree () functions. The description here may be a bit abstract, such as the installation of area blocks and the installation of system linked lists, but don't worry, because they are all defined by the author, wait until there is a special chart explanation, then you will be clear.
The do_kern_mount () function is used to create a new installation area block. The specific content has been described in the previous section VFS directory tree creation.
The graft_tree () function is to add a struct vfsmount type variable returned by the do_kern_mount () function to the installation system linked list, And graft_tree () add the newly assigned struct vfsmount type variable to a hash table. The purpose will be shown later.
In this way, when the do_kern_mount () function returns, the relationship between the new data structures is shown in Figure 4. The data structure in the Red Circle area is called the installation area block, which may be called e2_mnt as the pointer to the installation area block. The Blue Arrow curve forms the so-called installation system linked list.
After clarifying the data structure relationships formed after these functions are called, let's go back to the issues mentioned at the beginning of this chapter, after the ext2 file system is installed on "/dev, how to convert operations on this directory to operations on the ext2 file system. As shown in figure 5, the call to the sys_mount () function does not directly change the I _op and I _fop pointers in the inode (that is, the new_inode variable in the figure) structure corresponding to the "/dev" directory, in addition, the "/dev" corresponding dentry (that is, the new_dentry variable in the figure) structure is still in the directory tree of VFS and is not hidden from it. Correspondingly, the e2_entry corresponding to the root directory of the ext2 File System on hda2 is not replaced by new_dentry in the vfs directory tree as I originally thought. How is the conversion between them?
