What is the relationship between system calls, message passing, and interrupts?
All modern operating systems support multitasking. This means that the system is able to execute multiple processes at the same time; either in pseudo-parallel (when only one CPU is available) or nowadays with multi-core CPUs being common in parallel (one task/core).
Let's take the simpler case of only one CPU being available. This means that if you execute at the same time two different processes (let's say a web browser and a music player) the system is not really able to execute them at the same time. What happens is that the CPU is switching from one process to the other all the time; but this is happening extremely fast, thus you never notice it.
Now let's assume that while those two processes are executing, you press the reset button (bad boy). The CPU will immediately stop whatever is doing and reboot the system. Congratulations: you generated an interrupt.
The case is similar when you are programming and want to ask for a service from the CPU. The difference is that in this case you execute software code -- usually library procedures that are executing system calls (for example
fopenfor opening a file).Thus, 1 describes two different ways of getting attention from the CPU.
Most modern operating systems support two execution modes: user mode and kernel mode. By default an operating system runs in user mode. User mode is very limited. For example, all I/O is forbidden; thus, you are not allowed to open a file from your hard disk. Of course this never happens in real, because when you open a file the operating system switches from user to kernel mode transparently. In kernel mode you have total control of the hardware.
If you are wondering why those two modes exist, the simplest answer is for protection. Microkernel-based operating systems (for example MINIX 3) have most of their services running in user mode, which makes them less harmful. Monolithic kernels (like Linux) have almost all their services running in kernel mode. Thus a driver that crashes in MINIX 3 is unlikely to bring down the whole system, while this is not unusual in Linux.
System calls are the primitive used in monolithic kernels (shared data model) for switching from user to kernel mode. Message passing is the primitive used in microkernels (client/server model). To be more precise, in a message passing system programmers also use system calls to get attention from the CPU. Message passing is visible only to the operating system developers. Monolithic kernels using system calls are faster but less reliable, while microkernels using message passing are slower but have better fault isolation.
Thus, 2 mentions two different ways of switching from user to kernel mode.
To revise, the most common way of creating a software interrupt, aka trap, is by executing a system call. Interrupts on the other hand are generated purely by hardware.
When we interrupt the CPU (either by software or by hardware) it needs to save somewhere its current state -- the process that it executes and at which point it did stop -- otherwise it will not be able to resume the process when switching back. That is called a context switch and it makes sense: Before you switch off your computer to do something else, you first need to make sure that you saved all your programs/documents, etc so that you can resume from the point where you stopped the next time you'll turn it on :)
Thus, 3 explains what needs to be done after executing a trap or an interrupt and how similar the two cases are.
System calls, messaging passing (as described in the Wikipedia article), and interrupts are all things that cause a context switch or a switch from user to kernel mode. As you likely know:
kernel mode: programs have a flat or real view of memory, and programs can read/write freely to all memory and all hardware devices directly without restriction.
user mode: programs have a virtualized view of memory, programs cannot read/write freely to all memory and cannot read/write hardware devices directly. To obtain more memory or access hardware devices, the user mode program must call the kernel. System calls and message passing are two methods to do this.
System calls involve executing a specific CPU instruction or set of instructions, which make the CPU jump (first saving return address on the stack) to a predefined address (not writeable to user mode) and move the CPU from user mode to kernel mode (ring 3 to ring 0 in Intel architecture).
Hardware interrupts do much the same thing, they make the CPU jump (first saving return address on the stack) to a predefined address and move the CPU from user mode to kernel mode. So in many CPUs the same mechanism can be invoked by software (called a "software interrupt") and can be used for CPU calls.
Message passing implies (to me at least) that the kernel is a "running process" that will receive a stream of messages and that there exists a user-mode accessible function that will send such messages. Or it could be that the "send" function just shoves values on a stack and the next time the kernel has control (either if a process blocks or an interrupt occurrs) it pops messages off the stack and dispatches to internal routines accordingly.
In a microkernel architecture where the actual "kernel" is very minimal and most of the functions that a kernel provides are moved to "server" processes, all of which may be running concurrently on a multi-CPU system, something like this might be more useful than the plain old system call approach. Interpreting and routing "messages" to the appropriate kernel "server" would be one of the microkernel's few jobs.
Message passing is a higher level concept of one process sending a message to another. It is implemented by a system ( kernel ) call, asking the kernel to pass the message to the other process. System calls ask the kernel to perform various services for the process. They are implemented by a software interrupt / system trap, which causes the cpu to save some state on the stack so it can return later, then switch to kernel mode and jump to the kernel handler.
Both hardware and software interrupts cause the cpu to save state, switch to kernel mode, and jump to a defined handler for that interrupt. The difference is that hardware interrupts are generated by external hardware when they need some attention, such as a keyboard indicating that a key has been pressed. The keyboard handler then can go read the keyboard IO port to see what key was pressed, and take appropriate action, and then return to the program that was interrupted.