On the operating system, what's the difference between a system call and an interrupt?

Question

In the operating system, what is the difference between a system call and an interrupt? Are all system calls interrupted? Are system calls all interrupted?

Answer 1

Short answer: These are two different things.

• A system call is a call by software running on the OS to the services provided by the OS.
• An interrupt is usually an external hardware component that notifies the CPU / microprocessor of an event that requires processing in software (usually a driver).

I usually say external, because some interrupts can be raised by software (soft interrupt)

Are all system calls interrupted? Depends

Are system calls all interrupted? No

Long answer: The OS controls the time of the processor and other equipment connected to the CPU (memory (RAM), HDD, keyboard, to name a few). It provides services that allow user programs to access basic equipment, and these are system calls. This usually refers to allocating memory, reading / writing files, printing a document, etc.

When the OS interacts with other equipment, it usually does this through the driver level, which configures the task for the hardware to complete and interrupt after the job is completed, so the printer may interrupt after the document is printed or it is launched from pages. Therefore, it often happens that a system call leads to the generation of interrupts.

Interruptions of all system calls - depends on how they can be implemented as soft interruptions. Therefore, when the user program makes a system call, it causes a soft interrupt, which leads to the suspension of the OS call process and processing of the request itself, and then the process resumes. But, and I quote from Wikipedia,

“For many RISC processors, this (interruption) is the only way provided, but CISC architectures such as x86 support additional methods. One, for example, SYSCALL / SYSRET, SYSENTER / SYSEXIT (the two mechanisms were independently created by AMD and Intel respectively, but essentially do the same). These are “quick” control transfer instructions that are designed to quickly transfer OS control to the system call without interruption overhead "

Answer 2

The answer to your question depends on the underlying hardware (and sometimes the operating system). I will come back to this a bit.

The purpose of the interrupt handler and system call (and error handler) is basically the same: switch the processor to kernel mode, providing protection against inadvertent or malicious access to kernel structures.

An interrupt is triggered by an asynchronous external event. A system call (or an error or a trap) is launched synchronously, executing the code.

Then the answer to your first question.

The answer to the question in your section is that system calls are not interrupts because they are not triggered asynchronously by the hardware. A process continues to execute its code stream in a system call, but not in an interrupt.

However, Intel documentation often links interrupts, system calls, traps, and errors like interrupts.

Some processors handle system calls for traps, crashes, and interrupts in much the same way. Others (especially Intel) provide various methods for making system calls.

In processors that process all of the above in the same way, each type of interrupt, trap, and error has a unique number. The processor expects the operating system to configure a vector (array) of pointers to the handlers. In addition, there is one or more handlers available for the operating system to make system calls.

Depending on the number of available handlers, the OS may have a separate handler for each system call or use the value of the register to determine the specific function of the system.

In such a system, an interrupt handler can be executed synchronously in the same way as one calls a system call.

For example, on VAX

CHMK # 4

calls the 4th kernel mode handler. In the world of intellectual property, this

INT

which does roughly the same thing.

Intel processors support the SYSCALL mechanism, which provides another way to implement system calls.