0

This may be very foolish question to ask. However I want to clarify my doubts as i am new to this thing.

As per my understanding the CPU executes the instruction of a process step by step by incrementing the program counter.

Now suppose we have a system call as one of the instruction, then why do we need to give a software interrupt when this instruction is encountered? Can't this system call (sequence of instructions) be executed just as other instructions are executing, because as far i understand the interrupts are to signal certain asynchronous events. But here the system call is a part of the process instruction, which is not asynchronous.

Sumit Trehan
  • 3,985
  • 3
  • 27
  • 42
  • because the actual code for the syscall EXPECTS to be called as an interrupt, which requires the registers/stack pointers/etc... have a certain structure to them. doing a `call address_of_syscall will not provide that same structure, and now you'll trash your system when that syscall returns and tries to undo the expected syscall preparation – Marc B Oct 03 '14 at 17:00
  • related [Stack Overflow: The difference between Call Gate, Interrupt Gate, Trap Gate?](http://stackoverflow.com/questions/3425085/the-difference-between-call-gate-interrupt-gate-trap-gate) and [Wikipedia: System call](http://en.wikipedia.org/wiki/System_call) – xmojmr Oct 03 '14 at 18:54

2 Answers2

4

It doesn't require an interrupt. You could make an OS which uses a simple call. But most don't for several reasons. Among them might be:

  1. On many architectures, interrupts elevate or change the CPU's access level, allowing the OS to implement protection of its memory from the unprivileged user code.

  2. Preemptive operating systems already make use of interrupts for scheduling processes. It might be convenient to use the same mechanism.

  3. Interrupts are something present on most architectures. Alternatives might require significant redesign across architectures.

Here is one example of a "system call" which doesn't use an interrupt (if you define a system call as requesting functionality from the OS):

Older versions of ARM do not provide atomic instructions to increment a counter. This means that an atomic increment requires help from the OS. The naive approach would be to make it a system call which makes the process uninterruptible during the load-add-store instructions, but this has a lot of overhead from the interrupt handler. Instead, the Linux kernel has chosen to map a small bit of code into every process at a fixed address. This code contains the atomic increment instructions and can be called directly from user code. The kernel scheduler takes care of ensuring that any operations interrupted in this block are properly restarted.

Dark Falcon
  • 43,592
  • 5
  • 83
  • 98
  • Can you link some "proofs" and "hard facts", e.g. exactly which small bit of Linux code is at the fixed address..? – xmojmr Oct 03 '14 at 19:00
  • 1
    It looks like the primary operation is actually compare-and-swap, but I was close. Atomic add is often implemented with CAS. In fact, there is an atomic add implementation included in this article: http://lwn.net/Articles/314561/ – Dark Falcon Oct 03 '14 at 19:31
0

First of all, system calls are synchronous software interrupts, not asynchronous. When the processor executes the trap machine instruction to go to kernel space, some of the kernel registers get changed by the interrupt handler functions. Modification of these registers requires privileged mode execution, i.e. these can not be changed using user space code.

When the user-space program cannot read data directly from disk, as it doesn't have control over the device driver. The user-space program should not bother with driver code. Communication with the device driver should take place through kernel code itself. We tend to believe that kernel code is pristine and entirely trustworthy; user code is always suspect.

Hence, it requires privileged instructions to change the contents of register and/or accessing driver functionalities; the user cannot execute system call functions as a normal function call. Your processor should know whether you are in the kernel mode to access these devices.

I hope this is clear to some extent.

Prune
  • 76,765
  • 14
  • 60
  • 81
Srinivas Desai
  • 21
  • 2