The role of interrupts

All things rely on interrupts to solve problems. This is especially true for computers, which rely on clock generators and artificially set a task every few clock cycles. Regardless of whether it is completed or not, once the specified time is up, it will be forced to "interrupt" to do the next task... In this way, until all tasks have been done (but not necessarily completed), then the first unfinished task will be done, and the cycle will repeat over and over again. This is the so-called "multitasking".
Otherwise, what if a CPU can type and see the screen at the same time? This is a CPU core, constantly detecting the keyboard and the screen...

There are also soft interrupts. For specific details, please refer to the principles of microcomputers.

Interrupt system

Interrupts, exceptions, and system calls

An interrupt is a reaction of the CPU to an event occurring in the system. The CPU suspends the executing program, preserves the scene, and automatically switches to execute the corresponding processing program. After processing the event, it returns to the breakpoint to continue executing the "interrupted" program.

Interrupts can be divided into three categories. The first category is caused by the outside of the CPU, called interrupts, such as I/O interrupts, clock interrupts, console interrupts, etc. The second category is the process caused by internal events from the CPU or events in program execution, called exceptions, such as processes caused by CPU failures (power supply voltage lower than 105V or frequency outside 47-63Hz), program failures (illegal opcodes, address out of bounds, floating point overflow, etc.).

The third type of process is caused by the use of system calls in the program to request system services, which is called a "trap". The first two types are usually called interrupts, which are often unintentional and passive, while traps are intentional and active.

       1. Interrupt processing

        Interrupt processing is generally divided into two steps: interrupt response and interrupt processing. Interrupt response is implemented by hardware, and interrupt processing is mainly implemented by software.

        (1) Interrupt response

        The entire processing process of the interrupt request is implemented by a set of interrupt mechanisms formed by combining hardware and software. When an interrupt occurs, the CPU pauses the execution of the current program and turns to processing the interrupt. This process of hardware responding to the interrupt request is called interrupt response. Generally speaking, the interrupt response sequence performs the following three steps:

◆Terminate the execution of the current program;

◆Save the breakpoint information of the original program (mainly the contents of the program counter PC and the program status register PS);

◆Take out the interrupt vector from the interrupt controller and transfer it to the corresponding handler.

Usually, after executing an instruction, the CPU immediately checks whether there is an interrupt request, and if so, it responds immediately.

The system responds when interrupts occur, whether they come from hardware (such as from a clock or external device), programmatic interrupts (the execution of instructions causes "software interrupts"), or from unexpected events (such as accessing a page that is not in memory).

If the current CPU execution priority is lower than the interrupt priority, then it will terminate the execution of the next instruction of the current program, accept the interrupt, and increase the execution level of the processor (generally the same as the interrupt priority) so that when the CPU handles the current interrupt, it can shield other interrupts of the same level or lower level, and then save the breakpoint scene information and jump to the entry of the corresponding interrupt handler through the obtained interrupt vector.

(2) Interrupt processing

The CPU obtains the interrupt vector from the interrupt controller, and then finds the corresponding table entry from the interrupt vector table IDT according to the specific interrupt vector, which should be an interrupt gate. Therefore, the CPU reaches the entrance of the general service program of the channel according to the setting of the interrupt gate.

The order in which the core handles interrupts is mainly completed by the following actions:

◆Save the contents of the registers of the running process and put them into the new frame of the core stack.

◆Determine the "source of the interrupt" or check the occurrence of the interrupt, identify the type of interrupt (such as clock interrupt or disk interrupt) and the device number of the interrupt (such as which disk caused the interrupt). When the system receives an interrupt, it gets an interrupt number from the machine, which is the displacement to retrieve the interrupt vector table. The interrupt vector varies from machine to machine, but usually includes the entry address of the corresponding interrupt handler and the status word of the processor when the interrupt is processed.

◆The core calls the interrupt handler to process the interrupt.

◆Interrupt processing is completed and returns. After the interrupt handler is executed, the core executes a specific instruction sequence related to the machine, restores the register content at the time of the interrupt and pops the execution core stack, and the process returns to the user state. If the rescheduling flag is set, the process is scheduled when the process returns to the user state.

2. System calls

In Unix/Linux systems, system calls appear in C programs like ordinary C function calls. However, ordinary function call sequences cannot change the state of a process from user mode to kernel mode, while system calls can do so.

The C language compiler uses a predetermined function library (generally called the C library), which contains the names of various system calls. The functions in the C library use a dedicated instruction to change the running state of the process to the kernel state. The Linux system call is implemented through the interrupt instruction "INT0x80".

Each system call has a unique number, called the system call number. All system calls are centrally managed in the system call entry table.

The system call entry table is an array of function pointers. By finding the corresponding function pointer in the array with the system call number as the subscript, we can determine which system call the user is using. The number of system calls in different systems is different. Currently, there are 221 system calls defined in the Linux system.

In addition, there are some remaining items in the system call table for users to add.

When the CPU executes the interrupt instruction "INT0x80", the hardware responds in a series of ways, the actions are the same as the above interrupt response. The CPU passes through the trap door and enters the system space from the user space. Accordingly, the context of the process is switched from the user stack to the system stack.

Then run the kernel function system_call(). First, further save the contents of each register; then call syscall_trace(), use the system call number as the index to search the system call entry table sys_call_table, find the corresponding function; then turn to execute the function to complete the specific service.

After executing the service program, the core checks whether an error occurs and handles it accordingly. If the process receives a signal, it handles the signal accordingly. Finally, the process returns from the system space to the user space.

The above two lectures briefly introduced the main data structures and corresponding algorithms of the Linux kernel. The Linux kernel contains a lot of content, and here is just a little bit of it, in order to play a role of "starting a discussion".

Signal interruption and system call restart

#include