2 minute read

We have been talking about system call for a while, e.g. applications request services from the operating system via syscall, but we have never ever seen a system call!

1. Where are they? — Layering

First, let’s recall the UNIX system structure:


System call is an interface between the user and kernel mode which is not necessarily the interface that you want to give a programmer for security concerns.


Consequently, system call is buried in the programming language run time library (e.g. libc.a) so it is the C library that actually makes the system calls to the operating system for us.

2. The charming “narrow waist” — The power of uniformed API


System calls show their power when we are dealing with multiple different devices. When their syscall are similar enough, mounting them become easy.

// It is said that the way Linux deals with it is to encompass every system call under the sun from all kinds of different operating systems. Terrific ~

Normally, we will get a different chunk of data reading from different devices but, due to the virtue of uniformity, we are able to read from and write to disk driver in exactly the same way as we read from and write to a flash memory. This is because the interface of the kernel is byte-oriented, which means it is reading and writing bytes so it doesn’t care the size of the data blocks.

3. Final notes: kernel-buffered read && write

Recall the six key design concepts of UNIX I/O

  • Uniformity

    • File operations, device I/O, and interprocess communication through open, read/write and close.
    • Allow simple composition of programs, for example, find | grep | wc ….
  • Open before use

    • Provides opportunity for access control and arbitration.
    • Sets up the underlying machinery, i.e., data structures.
  • Byte-oriented

    • Even if data blocks are transferred, addressing is in bytes.
  • Kernel buffered reads

    • Streaming and block devices look the same.
    • Read blocks processes, yielding processor to other task.
  • Kernel buffered writes

    • Completion of out-going transfer decoupled from the application, allowing it to continue.
  • Explicit close

As we discussed in the training session, reading something off a disk is time-consuming and costly, often up to several milli-seconds, which is roughly equal to a million instruction times. Thus, in order not to lose a million instructions, we better put the corresponding processes into sleep yielding processors to other tasks.

Same for writing, when the system call write returns, the data is not necessarily on the disk but buffered in the memory (the kernel), allowing the applications to keep going.

In a nutshell, the kernel is doing tons of buffering and visualization behind the scenes.

(In other words, if your machine crashes at a wrong point in time, you will lose your data permanently …)

p.s. I’ll (hopefully) get to the user-buffered I/O later.

Leave a comment