Implementation of fsync driven by Linux kernel

The fasync mechanism implements the notification mechanism through the SIGIO signal sent by the kernel, instead of the IO model in the Linux kernel through sleep wake-up:

1. synchronous blocking I/O
2. synchronous non-blocking I/O
3. asynchronous blocking of I/O
4. asynchronous non-blocking I/O


Synchronization: the application explicitly accesses data through the function. when this function is returned, the result (success or failure) is obtained ).
Asynchronous: the application displays the request for access or follow-up through the function. When the data arrives, the hardware and driver will notify the application. in this case, the code is generally not in the read/write access function, but is notified to access the data for a purpose.

Blocking: when waiting for data, it will sleep here, instead of blocking. that is, the function will return immediately if it does not sleep. you can execute the following code.

These four mechanisms are explained in "deep into Linux device driver kernel mechanism". for asynchronous non-blocking I/O, the kernel provides two implementations: aio, the other is fasync. Aio should be regarded as a relatively new framework, which is more complex. I have not studied it in depth. I will summarize it later. For fasync, the in-depth Linux device driver kernel mechanism has detailed explanations and experiments. after reading this knowledge, I am as usual, draws a diagram to sort out all the code associations. This figure was painted two months ago and was delayed due to my baby and work.



(We recommend that you download the image to your local device for comparison)

To understand the kernel's fasync mechanism, you can combine the diagram with the explanation in "deep Linux driver kernel mechanism. Based on this flowchart, I will summarize my understanding:
First, the fasync mechanism implements the notification mechanism through the SIGIO signal sent by the kernel, not through sleep.
From this perspective, the application must do the following:
1. install SIGIO signals (when signal routines process accessible kernel data)
2. tell the kernel the ID of the process to be notified
3. set the FASYNC flag. the kernel will call the fasync method through the driver to prepare for future signal notifications.


After the application completes the relevant settings, it can do other things. if there is any problem, the kernel will send a SIGIO signal notification, and the signal routine installed by the application will be called.


On the kernel space side, related drivers need to implement the following work:
1. define a global struct fasync_struct pointer;
2. to implement the fasync method in file_operations, call the auxiliary function fasync_helper of the kernel.
3. call the kill_fasync function in a routine that can obtain data access information.


With the combination of the above kernel and application, you can easily use the kernel asynchronous notification mechanism. This mechanism is easy to use and looks at. at first, it was quite complicated. once we had a thorough understanding of all the relevant structures and routines, we would find that, in fact, the implementation of this mechanism is also clear. I personally think that for kernel learning, we must first clarify the relationship between architectures and data structures. Looking at other people's code analysis can give you a proper understanding of the architecture. The final key is your own RTFSC. Therefore, I usually do not analyze the code in blog posts, but only the architecture and diagrams. the code needs to be analyzed by interested friends.