Read the fuse kernel source code again.

When the fuse kernel module is loaded, the following initialization routine is called. For details, see fuse_init function <inode. c>.

1. fuse_fs_init (); register the fuse file system and create the fuse_inode cache.

2. fuse_dev_init (); Create fuse_req high-speed cache and load the fuse Device Driver for information exchange between user space and kernel space.

3. fuse_sysfs_init (); Add the fuse node under the/sys/fs directory and add the connections node under the fuse node.

4. fuse_ctl_init (); register the fuse Control File System

 

When the fuse kernel module is uninstalled, perform the corresponding cleaning. For details, see fuse_exit function <inode. c>.

1. fuse_ctl_cleanup (); log out of the fuse Control File System

2. fuse_sysfs_cleanup (); remove fuse and connections nodes.

3. fuse_fs_cleanup (); log out of the fuse file system and release the fuse_inode cache.

4. fuse_dev_cleanup (); log out of the fuse device driver and release the fuse_req cache.

 

Fuse_conn <fuse_ I .h> indicates a fuse connection. This structure is generated when the user's file system is mounted. When the file system is detached, this structure is released. It is mainly used to manage Request queues, the kernel maintains a fuse_conn linked list for all mounted file systems (the fuse file system may be mounted multiple times ).

 

The connected field of fuse_conn is used to indicate the connection status. After successful mounting, it is set to 1. When the file system is detached, the connection is interrupted, or the device driver is released, this field is set to 0, in this case, the connection (mounted file system) cannot provide normal services. This field is checked in fuse_request_send. Requests are sent only when the fuse file system is connected normally.

 

Each request in fuse is represented by a fuse_req <fuse_ I .h> structure, which contains the input and output parameters of the fuse request, inode and file of the request object.

 

Each fuse input and output parameter supports three parameters. For details, see the definition of the fuse_in and fuse_out structures <fuse_ I .h>. The parameters are passed in the form of <* value, size>, when filling the fuse_req structure, set the number of fuse_in parameters (numargs) based on the request type and request parameters, fill the parameters in the ARGs array, and set the number of fuse_out output parameters, and fill in the address (local variable outarg) that stores the output result into The args array.

 

After the fuse file system sets the request input and output parameters, all interfaces call fuse_request_send to set the status flag representing the fuse_req structure of this request to fuse_req_pending, add the request to the pending linked list of fuse_conn and call request_wait_answer to wait for the request to complete (after the queue is awakened, check whether the request status is fuse_req_finished ). After the request is responded, the result is stored in the outarg local variable. Then, fuse can process the response and return the result to the upper layer.

 

Each request fuse_req structure contains a wait_queue_head_t waitq field. After each request is sent, it will first wake up the waitq waiting queue of fuse_conn and tell the user-mode daemon that the request has been reached; then it will call wait_event_interruptible to sleep on the waitq of req and wait for the fuse_req_finished condition to become true.

 

The fuse device driver is a simple block device driver used for fuse to exchange data between user and kernel states. Fuse contains a user space daemon which runs cyclically, the main task is to call read to read requests from the fuse device. When there is no request, it will sleep and wait on the waitq of fuse_conn (corresponding to the waitq waiting queue of fuse_conn after the request in the previous section is sent ), when a request is obtained from the pengding queue of fuse_conn (corresponding to the pending linked list of fuse_conn after the previous request is sent), the request is moved to the processing queue, after the daemon reads the relevant information of fuse_req to the user State, it calls the callback function implemented by the user State according to the request, and writes the result to the fuse device driver through fuse_dev_write. After the user State request is complete, find the corresponding fuse_req from the processing queue, copy the result to the out parameter of fuse_req, and set the state of fuse_req. Set to fuse_req_finished, and then wake up the waitq of fuse_req. After fuse_req is processed, the fuse file system returns the result to the upper layer.

 

For more information about fuse, see my blog FUSE:

Http://blog168.chinaunix.net/space.php? Uid = 20196318 & Do = Blog & frmd = 1570 & view = me