Language Selection

English French German Italian Portuguese Spanish

How System Calls Work in Linux?

Filed under

Every GNU/Linux programmer here reading this article must have used system calls to code their programs. GNU/Linux programming is incomplete without system calls. System calls are initiated by software interrupts. Before we delve into that, however, let’s define system calls.

A system call is the mechanism used by an application program to request service from the operating system, or more specifically, the operating system kernel.

Modern processors execute instructions in different privilege states. In system, where just two levels are defined (as in i386), these states are known as user mode and supervisor mode. These privilege levels are defined so that an operating system restrict can control the operations performed by the program. Controlling is done for reasons of security and stability. The kernel of the operating system should always run in privilege mode since it needs to do some operations. Such operations include accessing hardware devices, enabling and disabling interrupts, changing privileged processor state, and accessing memory management units.

Now with this setup of an operating system (with two modes of execution (considering only i386 architecture only)), we need a mechanism to transfer control safety from lesser privileged modes to higher privileged modes.

Full Story.

More in Tux Machines

Super long-term kernel support

In the longer-term, CIP is looking toward IEC-62443 security certification. That is an ambitious goal and CIP can't get there by itself, but the project is working on documentation, test cases, and tools that will hopefully help with an eventual certification effort. Another issue that must be on the radar of any project like this is the year-2038 problem, which currently puts a hard limit on how long a Linux system can be supported. CIP is working with kernel and libc developers to push solutions forward in this area. Read more

LibreSSL 2.7.1 Released, OpenSSH 7.7 Being Tested

today's howtos

Programming: Python 2.*, Functional Computation, and Plagiarism in CS

  • 1.5 Year Warning: Python2 will be End of Lifed
    The end of upstream Python 2.7 support will be January 1, 2020 (2020-01-01) and the Fedora Project is working out what to do with it. As Fedora 29 would be released in 2019-11 and would get 1.5 years of support, the last release which would be considered supportable would be the upcoming release of Fedora 28. This is why the current Python maintainers are looking to orphan python2. They have made a list of the packages that would be affected by this and have started a discussion on the Fedora development lists, but people who only see notes of this from blogs or LWN posts may not have seen it yet.
  • Why is functional programming seen as the opposite of OOP rather than an addition to it?

    So: both OOP and functional computation can be completely compatible (and should be!). There is no reason to munge state in objects, and there is no reason to invent “monads” in FP. We just have to realize that “computers are simulators” and figure out what to simulate.

  • Why we still can’t stop plagiarism in undergraduate computer science

    The most important goal is to keep the course fair for students who do honest work. Instructors must assign grades that accurately reflect performance. A student who grapples with a problem — becoming a stronger programmer in the process — should never receive a lower grade than one who copies and pastes.


    University administrators should communicate their support. Instructors should know that, not only will they suffer no retaliation, but that the university encourages them to enforce university policies. This might require administrators to acknowledge the inconvenient truth of widespread plagiarism.