System Calls and Dual-Mode Operation for GATE: The Trap Gateway and OS Structures

Separate the mode bit, privileged instructions and the system-call trap. Then use one protection rule to classify operations and compare common kernel structures.

KnowledgeGate Team

Exam prep & CS education

Updated 17 Aug 20266 min read

The recurring question is deceptively small: which instructions must be privileged, and how does a user program get one performed without being allowed to execute it? The trouble starts when system call, trap, mode bit and privileged instruction blur into a single idea. Separate their roles, and a long option list becomes easy to classify.

Dual-mode operation and the mode bit

An operating system must let applications use the processor without letting them take control of the whole machine. Dual-mode operation supplies that protection. The CPU carries a single hardware mode bit, and its value selects one of two execution modes:

  • kernel mode, represented by mode bit 0

  • user mode, represented by mode bit 1

Kernel mode is also called supervisor or privileged mode. The operating system kernel runs there. Ordinary applications run in user mode with restricted authority.

The mode bit is maintained and enforced by hardware. A user program cannot simply write 0 into it. A controlled event such as a system-call trap, interrupt or exception transfers control to a kernel entry point, and the hardware changes the mode as part of that transfer. On return, execution resumes in user mode.

This is the boundary: user code can request a service, but only trusted kernel code decides what privileged action is performed.

Privileged versus non-privileged instructions

A privileged instruction may execute only in kernel mode. If a user-mode program attempts it directly, hardware raises an exception and gives control to the OS. Typical privileged operations include:

  • direct device I/O

  • halting the processor

  • disabling interrupts

  • setting the interval timer

  • loading memory-management registers such as relocation or limit registers

  • changing the processor's execution mode directly

These operations can affect other programs, bypass protection or stop the OS from regaining control. That leads to the most useful classification rule:

If an instruction can defeat protection or alter machine-wide control, it must be privileged.

Arithmetic, logic, register-to-register moves and loads or stores within the process's permitted address space are non-privileged. They work only on the calling program's own legal state, so allowing them in user mode does not hand over the machine.

What a system call actually is: the trap gateway

A system call is a controlled request for a kernel service. It is not the privileged device operation itself. A user program often calls a library wrapper such as read(). The wrapper places the system-call number and arguments in agreed locations, then executes the architecture's trap or syscall instruction.

The sequence is:

  1. The user program prepares a call number and arguments.

  2. It executes the controlled trap instruction.

  3. Hardware transfers to a fixed kernel entry point and changes mode from 1 to 0.

  4. The kernel validates the request and indexes a system-call dispatch table using the call number.

  5. The selected handler performs the service.

  6. The kernel places the result for the caller and executes a protected return.

  7. Hardware restores user mode, with the mode bit changing from 0 to 1.

The call number, not the instruction, picks the dispatch-table entry, so the kernel can add services without ever changing the gateway. This is why exam questions track the call number and dispatcher, not merely a source-language function name. A library function need not cause a system call at all. Some functions compute entirely in user space, and a wrapper may also avoid a trap when the OS exposes a safe fast path.

A read() system call trapping from user mode into the kernel and back, with the mode bit flipping and the dispatcher selecting the handler.

The five categories of system calls

System calls fall into five main categories:

Category

Purpose

Typical examples

Process control

Create, replace, wait for or terminate execution

fork, exec, wait, exit

File management

Work with files and descriptors

open, read, write, close

Device management

Request, release or control devices

device request, device release, ioctl

Information maintenance

Read or update system and process information

getpid, time, get/set system data

Communication

Exchange data between processes or machines

pipes, message queues, shared memory, sockets

Some texts split out a sixth category, protection, covering calls that set or change access permissions on a file or resource, such as chmod.

OS structures: monolithic, layered, microkernel and modular

A monolithic kernel keeps major services such as scheduling, memory management, file systems, device drivers and IPC in one kernel address space. Calls between services are fast, but a faulty kernel component can damage the whole system. Linux is commonly described as modular monolithic because it retains a monolithic core while supporting loadable modules.

A layered system arranges the OS as a hierarchy, with the hardware as layer 0 and the user interface at the top. Each layer uses only the services of the layer below, so a fault can be localised to the layer being debugged. Two costs follow: deciding which service belongs in which layer is hard, because no layer may depend on anything above it, and a request crossing several layers pays a call and a parameter copy at every boundary.

A microkernel keeps a small set of essentials in kernel space, usually low-level address-space support, basic scheduling and IPC. File systems and drivers can run as isolated user-space services and communicate by messages. Isolation improves fault containment, while extra communication and context changes can cost performance. Mach, MINIX and QNX are the standard microkernel examples.

A modular or hybrid design keeps a protected core and loads the rest as modules at run time. A module is linked into the running kernel without recompiling or rebooting it and reaches the core through a defined interface, so the design gains microkernel-style flexibility while service calls stay ordinary in-kernel calls rather than messages. Solaris is the textbook example, and Windows and macOS are commonly described as hybrids.

One axis separates all four: where a service runs. Inside the kernel, a driver's calls are cheap and its bugs are the kernel's bugs. In user space, a driver crash costs one restartable service plus a message round trip on every request.

Two OS layouts: a monolithic kernel holding every service, and a microkernel with file systems and drivers as separate user-space services.

Fully worked example: classify these operations

Apply the protection rule to each operation before thinking about familiar names.

  1. Add two CPU registers: non-privileged. This is pure computation on the program's own state and needs no system call.

  2. Disable all interrupts: privileged. Otherwise a user program could prevent the OS timer from regaining the CPU.

  3. Read wall-clock time: requested through an information-maintenance interface in the textbook model. Direct access to protected clock hardware is not given to user code.

  4. Switch directly from user to kernel mode: privileged. A user program enters only through a controlled trap, not by editing the mode bit.

  5. Load from the program's own valid memory: non-privileged. Memory protection still checks the address.

  6. Write directly to a disk-controller register: privileged. Direct device control can affect the system and other processes.

  7. Set the interval timer: privileged. The timer ensures the OS can regain control, so an application cannot set it directly.

If the options ask which operations must be privileged, select disabling interrupts, direct disk I/O, setting the timer and setting the mode directly. The two computation and legal-memory operations are non-privileged. The time request is a service request, which is distinct from direct hardware access.

How GATE tests this and the traps

Expect instruction classification, the order of a system-call transition, or a property match between kernel structures. A statement such as "a user-space driver failure can be isolated from the kernel" points towards a microkernel arrangement. A statement about direct procedure calls among kernel services points towards a monolithic design.

The biggest traps are calling every library function a system call and treating the trap instruction as an unrestricted way to enter any kernel address. The entry target and mode change are hardware-controlled. Check current syllabus and weightage details on the official GATE portal of the organising IIT.

For targeted practice, solve Operating System Basics MCQs: 12 solved questions on OS structure, then use Operating Systems for GATE: How to Study Deadlocks, Scheduling and Memory to connect protection and structure with the rest of the subject.

The short version and your next step

The mode bit protects privileged instructions. A system call is the checked trap gateway into a numbered kernel handler. Kernel structures then decide where OS services run and what isolation or overhead follows.

Build the full sequence with GATE Guidance by Sanchit Sir, test the distinctions under time in the GATE Test Series, and use the GATE CS preparation catalogue to plan the surrounding OS topics.