Are there any other interfaces, e.g. the /proc filesystem?
Linux – Are system calls the only way to interact with the Linux kernel from user land
Architecturekernellinuxsystem-calls
Related Solutions
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
fopen
for 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.
I don't have that book to check, but I assuming its using the normal meaning of system calls, then a system call is a call into the kernel to perform some operation the hardware considers privileged, or is unaware of. This is used to enforce permissions, etc. on the system. So you need to make a system call to (among many other things):
- read from a file (the kernel must check that the permissions allow you to read from said file, and then the kernel carries out the actual instructions to the disk to read the file)
- signal a process (processes do not exist as far as the hardware is concerned, they are an abstraction provided by the kernel, etc.)
- obtain additional memory (the kernel must make sure you don't exceed the ulimit, make sure two processes don't claim the same RAM, etc.)
Math is not one of those things. Typically, it requires no intervention from the kernel.
Best Answer
The Linux kernel syscall API is the the primary API (though hidden under libc, and rarely used directly by programmers), and most standard IPC mechanisms are heavily biased toward the everything is a file approach, which eliminates them here as they ultimately require read/write (and more) calls.
However, on most platforms (if you exclude all the system calls to get you there) there is a way: VDSO. This is a mechanism where the kernel maps one (or more) slightly magic pages into each process (usually in the form of an ELF .so). You can see this as
linux-vdso.so
or similar withldd
or in/proc/PID/maps
. This is effectively memory-mapped IPC between the kernel and a user process (albeit one-way in its current implementation).It's used to speed up syscalls in general and was originally implemented (
linux-gate.so
) to address x86 performance issues, but it may also contain kernel data and access functions. Calls likegetcpu()
andgettimeofday()
may use these rather than making an actual syscall and a kernel context switch. The availability of these optimised calls is detected and enabled by the glibc startup code (subject to platform availability). Current implementations contain a (read-only) page of shared kernel variables known as the "VVAR" page which can be read directly.You can check this by inspecting the output of
strace -e trace=clock_gettime date
to see if yourdate
command makes anyclock_gettime()
syscalls, with a working VDSO it will not (the time will be read from the VVARS page by a function in the VDSO page, seearch/x86/vdso/vclock_gettime.c
).There's a useful technical summary here: http://blog.tinola.com/?e=5 a more detailed tutorial: http://www.linuxjournal.com/content/creating-vdso-colonels-other-chicken , and the man page: http://man7.org/linux/man-pages/man7/vdso.7.html