OS services and design goals

What users and programs can ask the OS to do

Start here

A service here means a well-defined capability the OS provides (create a process, map memory, open a file)- not “any helpful library.” If you are new to systems, memorize four buckets: execution, persistence, protection, and accounting; the rest of the course hangs examples on those hooks.

What are OS services? (theory)

Users want convenient abstractions: files instead of raw sectors, processes instead of raw CPU state, sockets instead of NIC ring buffers. The OS implements services by combining kernel mechanisms (data structures + syscall handlers) with policy (who gets priority, how much RAM, which capabilities a user has).

Design goals often conflict: throughput vs latency, simplicity vs extensibility, security vs convenience. A desktop OS optimizes interactivity; a batch cluster OS optimizes utilization. Cloud hosts add cgroups, namespaces, and quotas, still built from the same primitive services.

By the end of this page you should be able to

List four classic categories of OS services and give one syscall-level example of each.
Explain why resource accounting matters for fairness and for cloud billing.
Contrast authentication with authorization with a concrete file-access example.
Describe how user-space daemons still depend on kernel services (pick systemd + cgroups as an example).

Services vs mechanisms vs policy

Textbooks separate what is possible from what is chosen.

Mechanism

The how: e.g. a ready queue structure, page tables, a syscall dispatcher. Mechanisms should be general, you can change scheduling policy without rewriting the notion of a runnable thread.

Policy

The which / when: e.g. CFS weights, OOM killer heuristics, default ulimits. Policies encode organizational values (fairness, revenue protection, real-time deadlines).

Service (user-visible)

The what you ask for: “run this program,” “append to this file,” “sleep until data arrives.” Services are named contracts; mechanisms implement them under the hood.

Design goals (typical)

Reliability, security, convenience, efficiency, scalability, tradeoffs appear immediately when you enable strict MAC (SELinux) or aggressive power saving on laptops.

“Everything is a file” (Unix culture)

Many resources appear as file descriptors in a unified namespace. That design choice simplifies tools (dup2, redirection, /proc) but is not literally true for every object (eBPF maps, GPU memory). When learning, treat it as a unifying metaphor, not a physical law.

TL;DR

OS services include process management, file and I/O abstraction, communication, error detection, resource accounting, and protection, exposed through a controlled interface (syscalls + higher-level APIs).

Services are not random utilities, they map user goals onto hardware capabilities while preserving isolation and fairness. Understanding the service catalog helps you read man pages, design sandboxes, and reason about cloud VM vs container boundaries.

Service clusters (diagram)

Execution, persistence, and protection as cooperating areas.

Diagram text: the exact Mermaid definition below preserves the nodes, labels, and connections. Enable JavaScript to view the rendered diagram.

Read the diagram definition

flowchart TB
  subgraph exec[Execution services]
    S[Scheduler]
    I[IPC]
  end
  subgraph persist[Persistence]
    F[VFS + page cache]
  end
  subgraph guard[Protection]
    A[Authn/z authz]
    C[cgroups / LSM]
  end
  exec --> persist
  persist --> guard

Services cluster into execution, persistence, protection, and accounting. Cloud “managed services” still bottom out on these primitives, cgroups enforce accounting, namespaces approximate protection boundaries, and block storage maps to the same VFS+buffer-cache path.

Mechanism stack (expanded)

How textbooks stack responsibilities inside the kernel.

Process & thread management

Create/destroy, scheduling, IPC primitives backed by kernel data structures (`task_struct`, wait queues).

Memory services

Virtual memory, demand paging, kernel/object caches, and swap when overcommitted.

File & device I/O

Namespaces, permissions, caching, and uniform fd abstraction over heterogeneous drivers.

Protection & accounting

Credentials, capabilities, LSM hooks, and cgroup controllers enforce policy.

Examples of services → interfaces

Concrete syscall names anchor abstract definitions.

Examples of OS services vs where they often surface

Service	Example interface
Create process	`fork` / `posix_spawn`
Read file	`read` / `pread` / `mmap`
Wall clock time	`gettimeofday` / `clock_gettime`
Send packets	`socket` + `sendmsg` + NIC driver path

Key insights

Convenience vs microkernel purity

Linux implements many policies in-kernel for speed (e.g., page cache) even when a microkernel might push them to servers.

Resource limits are first-class

rlimits, cgroups, and quotas are OS services that prevent fork bombs and noisy neighbors, critical for multi-tenant systems.

Error surfaces are contracts

Return codes, signals, and `errno` are part of the API, applications rely on stable semantics after partial failures.

Security services compose

Authentication (who) and authorization (what allowed) combine with auditing and MAC (SELinux/AppArmor) for defense in depth.

Did you know?

“Everything is a file” on Unix is a unifying namespace design, not literally true for all objects, but it simplifies tools and permissions.

Accounting (CPU time, I/O bytes) underpins billing on clouds and fairness between tenants.

Many “OS services” are implemented by user-space daemons that still depend on kernel primitives (e.g., `systemd` + cgroups).

Pitfalls

“The OS is fair by default”: Fairness is policy; defaults optimize throughput unless you tune RT bands, cgroups, or IRQ affinity.
Conflating services with syscalls: Some services are purely user-space (windowing) but still depend on kernel primitives underneath.

Vocabulary

Accounting: Measuring and limiting resource consumption (CPU time, memory, IOPS).
LSM: Linux Security Modules, hooks for SELinux/AppArmor mandatory access control.
VFS: Virtual file system layer unifying multiple concrete filesystem implementations.

Interview questions

Give an example where improving throughput hurts tail latency.
Which OS service is exercised by a TLS web server under load?
How do containers remap “protection” without a new kernel?

API layering

libc wraps syscalls; many languages wrap libc. Debugging often crosses all three layers, know where errors originate.

User services vs kernel services

Printing to a terminal may involve line discipline in kernel TTY layer plus user-space font rendering in GUI stacks, the boundary shifts by platform.

Categorize

Pick five syscalls you use weekly and classify each as: process, file, net, time, or misc security.

Terminal

strace -c -f sleep 1

Self-check

1Which is closest to an OS “service” in the textbook sense?

2Resource accounting is important for…

3Authorization answers…