[FreeBSD] Traps and Interrupts

 

 

 

3.3 Traps and Interrupts

Traps, like system calls, occur synchronously for a process. Traps normally occur because of unintentional errors, such as division by zero or indirection through an invalid pointer. The process becomes aware of the problem either by catching a signal or by being terminated. Traps can also occur because of a page fault, in which case the system makes the page available and restarts the process without the process being aware that the fault occurred. 

 

The trap handler is invoked like the system-call handler. First, the process state is saved. Next, the trap handler determines the trap type and then arranges to post a signal or to cause a pagein as appropriate. Finally, it checks for pending signals and higher-priority processes, and exits like the system-call handler except that it has no return value.

 

 

 

https://www.microcontrollertips.com/exceptions-traps-and-interrupts-whats-the-difference-faq/

 

 

 

I/O Device Interrupts

Interrupts from I/O and other devices are handled by interrupt routines that are loaded as part of the kernel’s address space. These routines handle the console terminal interface, one or more clocks, and several software-initiated interrupts used by the system for low-priority clock processing and for networking facilities.

 

Unlike traps and system calls, device interrupts occur asynchronously. The process that requested the service is unlikely to be the currently running process and may no longer exist! The process that started the operation will be notified that the operation has finished when that process runs again. As occurs with traps and system calls, the entire machine state must be saved, since any changes could cause errors in the currently running process. (이건 공통점) 

 

Device-interrupt handlers run only on demand. Unlike the pre-multiprocessing versions of FreeBSD, modern FreeBSD kernels create a thread context for each device driver. Thus, just as one process cannot access the context of the previously running process, interrupt handlers cannot access any of the context of the previously running interrupt handler. The stack normally used by the kernel is part of a process context. Since each device has its own context, it also has its own stack on which to run.

 

Interrupts in pre-multiprocessing FreeBSD systems (멀티 프로세서 이전의 OS) had no context, so they had to run to completion without sleeping. In modern FreeBSD kernels, interrupts can block to wait for resources. However, while blocked they cannot be invoked with another event, so to reduce the chance for lost interrupts, most handlers still run to completion without sleeping. (이전 방식으로) 

 

An interrupt handler is never invoked from the top half of the kernel. Thus, it must get all the information it needs from the data structures that it shares with the top half of the kernel - generally, its global work queue. Similarly, all information provided to the top half of the kernel by the interrupt handler must be communicated the same way.

 

 

 

Software Interrupts

Many events in the kernel are driven by hardware interrupts. (대부분은 하드웨어 인터럽트) For high-speed devices such as network controllers, these interrupts are scheduled at a high priority. A network controller must quickly acknowledge receipt of a packet and reenable the controller to accept more packets to avoid losing closely spaced packets.

However, the further processing of passing the packet to the receiving process, although time-consuming, does not need to be done quickly. Thus, the further processing can be scheduled at a lower priority, so critical operations will not be blocked from executing longer than necessary.

 

The mechanism for performing lower-priority processing is called a software interrupt. (아 하 !! )

Typically, a high-priority interrupt creates a queue of work to be done at a lower-priority level. As with hardware devices in FreeBSD, each software interrupt has a process context associated with it.

The software-interrupt processes are generally given a lower scheduling priority than the device-driver processes but a higher priority than those given to user processes. (유저 프로세스와 디바이스 프로세스 사이의 소프트웨어 인터럽트)

Whenever a hardware interrupt arrives, the process associated with the device driver will attain the highest priority and be scheduled to run. When there are no device-driver processes that are runnable, the highest priority software-interrupt process will be scheduled to run. If there are no software-interrupt processes that are runnable, then the highest priority user process will run. (순차적으로 부여되는 priority) If either a software-interrupt process or a user process is running when an interrupt arrives and makes its device-driver process runnable, the scheduler will preempt the software-interrupt or user process to run the device-driver process. 

 

The delivery of network packets to destination processes is handled by a packet-processing function that runs at a lower priority than the network-controller device driver. As packets come in, they are put onto a work queue and the controller is immediately reenabled. Between packet arrivals, the packet-processing process works to deliver the packets. Thus, the controller can accept new packets without having to wait for the previous packet to be delivered. In addition to network processing, software interrupts are used to handle time-related events and process rescheduling.