Linux OS (Operating System): Kernel, Processes, Memory and File Systems with Worked Examples

Connect Linux commands to the OS mechanisms beneath them through exact traces of system calls, a two-process pipe, virtual address translation and file permissions.

KnowledgeGate Team

Exam prep & CS education

Updated 20 Sep 20266 min read

Linux is often revised as commands and Operating Systems as disconnected theory. You may know fork, paging and permissions without seeing one running system. Exact system-call, pipe, address-translation and permission examples connect user space to the kernel.

Linux OS explained: connect the kernel to the Operating Systems syllabus

Linux is the kernel. It schedules tasks, manages virtual memory, exposes system calls, implements networking, and coordinates filesystems and drivers. A usable system also needs user-space libraries, shells, utilities and applications. A distribution packages them with the kernel.

layer

examples

job

applications

editor, browser, database

request work

shell and utilities

bash, cp, ps

provide user-facing programs

libraries

libc

wrap many system-call interfaces

Linux kernel

scheduler, virtual-memory manager, VFS, networking, drivers

manage protected OS mechanisms

hardware

CPU, RAM, disks, devices

supply computing and storage resources

A library call need not cause a system call, but a system call crosses from user mode into kernel mode. Keep kernel, shell and distribution separate.

Start with Linux Operating System: Kernel, Processes, Files and Worked Examples for the broad relationships among the kernel, shell, distribution, processes, memory and files. Use the trace-led checks below for exact return values: a 1,500-byte copy, a two-process pipe, one address translation and a permission change. The GATE CS Exam Preparation Courses & Test Series category places both paths in the wider preparation sequence.

User mode, kernel mode and system calls: trace one 1,500-byte copy

In this simplified model of cp report.txt /archive/report.txt, the source has 1,500 bytes and cp is PID 2401.

  1. openat opens report.txt and returns file descriptor 3.

  2. Another openat opens the destination and returns descriptor 4.

  3. read(3, buffer, 4096) returns 1500.

  4. write(4, buffer, 1500) returns 1500.

  5. The next read(3, buffer, 4096) returns 0, meaning end-of-file, then descriptors 3 and 4 are closed.

The pathname and buffer start in user space. System-call entry transfers control to the kernel, which validates the descriptors and buffer, uses the VFS and filesystem, then returns a byte count or error. Descriptor 3 is a process-local integer referring to an open-file description, not a disk address. read returning 0 is EOF, not failure.

Applications do not become the kernel. User code cannot perform privileged device or page-table operations directly, so the kernel checks each request. A system call is intentional, a hardware interrupt is an asynchronous device event, and an exception follows synchronously from an instruction. Each enters kernel code for a different reason. Real cp implementations may use optimised calls. Regardless of the call mix, each successful call returns a byte count and EOF arrives as a zero-length read.

cp system calls crossing the user-kernel boundary into VFS, filesystem, block layer and storage, with returns 3, 4, 1500, 1500 and 0.

Processes, scheduling and IPC: follow a two-process Linux pipe

For /usr/bin/printf "kernel\nprocess\n" | /usr/bin/wc -l, bash PID 4100 creates a pipe with read descriptor 3 and write descriptor 4. It forks producer PID 4101 and consumer PID 4102; each child uses exec for its external program.

PID 4101 writes 15 bytes, 7 for kernel\n plus 8 for process\n. PID 4102 counts two newlines and prints 2. Each process closes unused pipe ends. One open write end can keep the reader waiting because EOF requires every write reference to close.

A process is a running program context with a PID. Linux represents schedulable processes and threads as tasks; threads share process resources. fork creates a child, commonly with copy-on-write instead of immediate physical-page copies. exec replaces its image without a new PID. wait collects termination; until then, a terminated child is a zombie. A blocking read can put a task to sleep; a context switch runs another task.

Linux chooses among runnable tasks, but policy varies by kernel and configuration. CPU scheduling: FCFS, SJF, Round Robin & priority covers generic algorithms and calculations. None fully describes the Linux scheduler.

Linux virtual memory: translate 0x2B6D9 and explain a page fault

Assume a 32-bit virtual address, 4 KiB = 2^12 byte pages and virtual address 0x2B6D9 in a single-level teaching model.

step

calculation

result

offset

lower 12 bits

0x6D9 = 1753

virtual page number

0x2B6D9 >> 12

0x2B = 43

mapped frame

PTE[0x2B]

0x6E

frame base

0x6E << 12

0x6E000

physical address

0x6E000 + 0x6D9

0x6E6D9

A translation lookaside buffer can cache this mapping. On a miss, page-table machinery finds it. A non-resident valid PTE causes a page fault; the kernel may load or create the page, update the PTE and retry. This is not automatically a crash. An invalid access can cause a protection failure and signal.

Under copy-on-write, parent PID 4100 and child PID 4101 may map one frame read-only. A child write lets the kernel allocate a frame, copy one page and update the child's PTE, preserving the parent's data. Memory management in OS: paging & segmentation gives the generic foundation. Production Linux uses multi-level, architecture-dependent page tables rather than a single-level table.

Linux filesystems, file descriptors and permissions with exact access results

For /srv/notes.txt, pathname lookup walks directory entries. An inode-like object holds metadata and data mapping; open returns a process-local descriptor for an open-file description. The VFS provides a common interface, while buffering and page cache can reduce storage access. These objects are related, not identical. Unlinking a pathname need not destroy data while an open reference remains.

-rw-r----- 1 asha oslab 1500 ... /srv/notes.txt is mode 0640: owner asha can read and write, group oslab can read, and others have nothing. Group member rahul can read but not write. mina, in neither class, gets neither permission through these bits.

After chmod g+w /srv/notes.txt, mode 0660 displays -rw-rw----. rahul gains write access; mina gains nothing. This assumes mode-bit evaluation without ACL override. ACLs, capabilities and privilege can change real outcomes.

write returning 1500 means the kernel accepted 1,500 bytes for the open file, not that they reached persistent media. Filesystem allocation differs from disk scheduling, and page-cache behaviour differs from durable format. Flush timing is not universal.

How GATE and technical interviews test Linux and OS concepts

Practise interpreting syscall returns, separating fork from exec, following process states and IPC, translating addresses, and reasoning about permissions. GATE and interview questions test these mechanisms through return values, state transitions, address splits and access outcomes.

Four rapid checks should now be immediate:

  • read(fd, buffer, 4096) returning 0 means EOF.

  • The pipeline prints 2.

  • 0x2B6D9 translates to 0x6E6D9 under the stated mapping.

  • rahul can read but not write at 0640, then can read and write at 0660.

Interview follow-ups ask why system calls need a privilege boundary, exec keeps its PID, a valid page fault need not be an error, and a descriptor is not an inode. KnowledgeGate offers about 60 Linux OS practice questions across kernel architecture, process scheduling, IPC, networking, file systems and I/O. Use the GATE Test Series for timed practice.

Linux OS traps, the short version and a concrete next step

  • Commands alone: They hide mechanisms, so attach each command to its syscall and resource.

  • fork copies all memory now: This misses copy-on-write, so separate mappings from copied pages.

  • Every page fault is a crash: This confuses demand paging with invalid access, so inspect validity.

  • Descriptor 3 is global: This breaks across processes, so treat it as a local handle.

  • Round Robin is the Linux scheduler: This mistakes a model for an implementation, so separate algorithms from version-dependent policy.

Recall: application or shell -> library wrapper where applicable -> system-call boundary -> kernel subsystem -> driver or storage or hardware -> checked return. Anchor it with 1,500 copied bytes, 15 pipe bytes producing 2, 0x2B6D9 -> 0x6E6D9, and 0640 -> 0660 after g+w.

Redraw the system-call diagram from memory, then explain every arrow aloud without using a command name as the explanation. Finally, explain how the copy, pipe, page translation and permission change use different kernel subsystems.