Chapter 15:
The Linux System I
Operating System Concepts Essentials – 2nd Edition
Silberschatz, Galvin and Gagne ©2013
Chapter 15: The Linux System
 Linux History
 Design Principles
 Kernel Modules
 Process Management
 Scheduling
Operating System Concepts Essentials – 2nd Edition
15.2
Silberschatz, Galvin and Gagne ©2013
Objectives
 Explore history of UNIX OS: the basis of Linux
 Examine Linux process model including:

Scheduling

IPC
 To look at memory management in Linux
 Explore how Linux implements file systems and
manages I/O devices
Operating System Concepts Essentials – 2nd Edition
15.3
Silberschatz, Galvin and Gagne ©2013
History
 Linux = modern, free OS based on UNIX standards
 First developed as small but self-contained kernel

1991 by Linus Torvalds

Major design goal: UNIX compatibility

Released as open source
 Legacy of collaboration from users all around the
world, mostly via Internet
 Designed to run efficiently and reliably on common
PC hardware

Also runs on a variety of other platforms
Operating System Concepts Essentials – 2nd Edition
15.4
Silberschatz, Galvin and Gagne ©2013
History
 Core Linux operating system kernel is entirely
original

It can run much existing (free) UNIX software,
 =>
entire UNIX-compatible OS w/o proprietary code
 Linux system has many, varying Linux
distributions including the kernel, applications,
and management tools
Operating System Concepts Essentials – 2nd Edition
15.5
Silberschatz, Galvin and Gagne ©2013
The Linux Kernel
 Kernels with odd version numbers are
development kernels
 Kernels with even numbers are stable
production kernels
Operating System Concepts Essentials – 2nd Edition
15.6
Silberschatz, Galvin and Gagne ©2013
The Linux System
 Linux uses tools developed as part of:

Berkeley’s BSD OS

MIT’s X Window System

Free Software Foundation's GNU project
 Main system libraries were started by GNU project,
with improvements provided by Linux community
 Linux networking-administration tools derived from
BSD code

Recent BSD derivatives (e.g., Free BSD) have
borrowed code from Linux in return
Operating System Concepts Essentials – 2nd Edition
15.7
Silberschatz, Galvin and Gagne ©2013
The Linux System
 Linux system maintained by loose network of
developers collaborating over Internet

Small number of public ftp sites acting as de facto
standard repositories
 File System Hierarchy Standard document
maintained by Linux community ensures compatibility
across various system components

Overall layout of standard Linux file system

Informs where configuration files, libraries, system
binaries, and run-time data files should be stored
Operating System Concepts Essentials – 2nd Edition
15.8
Silberschatz, Galvin and Gagne ©2013
Linux Distributions
 Standard, precompiled sets of packages, or
distributions, include:

Basic Linux system

System installation and management utilities

Ready-to-install packages of common UNIX tools
 Early distributions managed packages by providing
a means of unpacking files into appropriate places

Modern distributions include advanced package
management
Operating System Concepts Essentials – 2nd Edition
15.9
Silberschatz, Galvin and Gagne ©2013
Linux Distributions
 Early distributions included SLS and Slackware

Red Hat and Debian are popular distributions from
commercial and noncommercial sources,
respectively

Others include Canonical and SuSE
 RPM Package file format permits compatibility
among various Linux distributions
Operating System Concepts Essentials – 2nd Edition
15.10
Silberschatz, Galvin and Gagne ©2013
Linux Licensing
 Linux kernel is distributed under GNU General
Public License (GPL)

Terms set by Free Software Foundation

Not public domain: not all rights are waived
 Anyone using Linux or creating their own derivative
of Linux may not make derived product proprietary

Software released under GPL may not be
redistributed as binary-only product

Can sell distributions, but must offer source code too
Operating System Concepts Essentials – 2nd Edition
15.11
Silberschatz, Galvin and Gagne ©2013
Chapter 15: The Linux System
 Linux History
 Design Principles
 Kernel Modules
 Process Management
 Scheduling
Operating System Concepts Essentials – 2nd Edition
15.12
Silberschatz, Galvin and Gagne ©2013
Design Principles
 Linux: multiuser, multitasking system with full set of
UNIX-compatible tools
 Its file system adheres to traditional UNIX semantics

Fully implements standard UNIX networking model
 Main design goals:

Speed

Efficiency

Standardization
Operating System Concepts Essentials – 2nd Edition
15.13
Silberschatz, Galvin and Gagne ©2013
Design Principles
 Linux designed to be compliant with relevant POSIX
documents

At least two Linux distributions have achieved official
POSIX certification

Supports Pthreads and subset of POSIX real-time
process control
 Linux programming interface adheres to SVR4 UNIX
semantics, rather than to BSD behavior
Operating System Concepts Essentials – 2nd Edition
15.14
Silberschatz, Galvin and Gagne ©2013
Components of a Linux System
Operating System Concepts Essentials – 2nd Edition
15.15
Silberschatz, Galvin and Gagne ©2013
Components of a Linux System
 Linux is composed of three main bodies of code

Most important distinction is between kernel and all
other components
 Kernel responsible for maintaining important
abstractions of OS

Kernel code executes in kernel mode with full access
to all physical resources

All kernel code and data structures are kept in same
single address space
Operating System Concepts Essentials – 2nd Edition
15.16
Silberschatz, Galvin and Gagne ©2013
Components of a Linux System (Cont.)
 System libraries define standard set of functions
through which applications interact with kernel

Implements much of OS functionality that does not
need full privileges of kernel code
 System utilities perform individual specialized
management tasks
 User-mode programs (rich and varied), including
multiple shells like bourne-again (bash)
Operating System Concepts Essentials – 2nd Edition
15.17
Silberschatz, Galvin and Gagne ©2013
Chapter 15: The Linux System
 Linux History
 Design Principles
 Kernel Modules
 Process Management
 Scheduling
Operating System Concepts Essentials – 2nd Edition
15.18
Silberschatz, Galvin and Gagne ©2013
Kernel Modules
 Sections of kernel code that can be compiled,
loaded, and unloaded independently

E.g. device driver, file system, networking protocol
 Module interface allows third parties to write and
distribute proprietary device drivers or file
systems that could not be distributed under GPL
 Kernel modules allow Linux system to be set up
with a standard, minimal kernel

Without any extra device drivers built in
Operating System Concepts Essentials – 2nd Edition
15.19
Silberschatz, Galvin and Gagne ©2013
Kernel Modules
 Four components to Linux module support:

Module-management system

Module loader and unloader

Driver-registration system

Conflict-resolution mechanism
Operating System Concepts Essentials – 2nd Edition
15.20
Silberschatz, Galvin and Gagne ©2013
Module Management
 Supports loading modules into memory

Allows modules to talk to rest of kernel
 Module loading split into two separate sections:

Managing sections of module code in kernel memory

Handling symbols modules are allowed to reference
 Module requestor manages loading requested, but
currently unloaded, modules

Regularly queries kernel to see whether a
dynamically loaded module is still in use,

Will unload module when no longer actively needed
Operating System Concepts Essentials – 2nd Edition
15.21
Silberschatz, Galvin and Gagne ©2013
Driver Registration
 Allows modules to tell rest of kernel that a new
driver has become available
 Kernel maintains dynamic tables of all known
drivers

Provides set of routines to add or remove drivers
 Registration tables include the following items:

Device drivers

File systems

Network protocols

Binary format
Operating System Concepts Essentials – 2nd Edition
15.22
Silberschatz, Galvin and Gagne ©2013
Conflict Resolution
 Mechanism that allows different device drivers to
reserve hardware resources and protect those
resources from accidental use by another driver
 The conflict resolution module aims to:

Prevent modules from clashing over access to
hardware resources

Prevent autoprobes from interfering with existing
device drivers

Resolve conflicts with multiple drivers trying to
access same hardware:
1.
Kernel maintains list of allocated HW resources
2.
Driver reserves resources with kernel database first
3.
Reservation request rejected if resource not available
Operating System Concepts Essentials – 2nd Edition
15.23
Silberschatz, Galvin and Gagne ©2013
Chapter 15: The Linux System
 Linux History
 Design Principles
 Kernel Modules
 Process Management
 Scheduling
Operating System Concepts Essentials – 2nd Edition
15.24
Silberschatz, Galvin and Gagne ©2013
Process Management
 UNIX process management separates creation
and running of processes

fork() system call creates a new process

exec() runs a new program
 Under UNIX, a process encompasses all info that
OS must maintain to track context of a single
execution of a single program
 Under Linux, process properties fall into three
groups: identity, environment, and context
Operating System Concepts Essentials – 2nd Edition
15.25
Silberschatz, Galvin and Gagne ©2013
Process Identity
 Process ID (PID) - unique identifier for process

Used to specify processes to OS when application
makes system call to signal, modify, or wait for
another process
 Credentials - each process must have an
associated user ID and one or more group IDs

Determines process’s access rights
 Personality - Not traditionally found on UNIX
systems, but under Linux each process has an
associated personality identifier that can slightly
modify the semantics of certain system calls

Used primarily by emulation libraries to request that
system calls be compatible with certain specific
flavors of UNIX
Operating System Concepts Essentials – 2nd Edition
15.26
Silberschatz, Galvin and Gagne ©2013
Process Identity
 Personality - each process has an associated
personality identifier that can slightly modify
semantics of certain system calls

Used primarily by emulation libraries to request that
system calls be compatible with certain UNIX distros
 Namespace – specific view of file system hierarchy

Most processes share common namespace and
operate on a shared file-system hierarchy

But each can have unique file-system hierarchy with
its own root directory and set of mounted file systems
Operating System Concepts Essentials – 2nd Edition
15.27
Silberschatz, Galvin and Gagne ©2013
Process Environment
 Process’s environment inherited from its parent
 Composed of two null-terminated vectors:

Argument vector - command-line arguments used
to invoke the running program

Environment vector - “NAME=VALUE” pairs that
associates named environment variables with
arbitrary textual values
Operating System Concepts Essentials – 2nd Edition
15.28
Silberschatz, Galvin and Gagne ©2013
Process Environment
 Passing environment variables among processes
and inheriting variables from parent offer flexible
means of sharing information between components
 Environment-variable mechanism provides a
customization of OS

Can be set on a per-process basis, rather than
being configured for entire system
Operating System Concepts Essentials – 2nd Edition
15.29
Silberschatz, Galvin and Gagne ©2013
Process Context
 Constantly changing state of running program at
any point in time
 Scheduling context - most important part of
process context

Holds information that scheduler needs to suspend
and restart process
 Kernel maintains accounting information about
resources currently being consumed by process

And total resources consumed so far
Operating System Concepts Essentials – 2nd Edition
15.30
Silberschatz, Galvin and Gagne ©2013
Process Context (Cont.)
 File-system context applies to requests to open
new files

Current root and default directories used for new file
searches stored here
 Virtual-memory context of process describes the
full contents of its private address space
 Signal-handler table defines routines (in process’s
address space) to be called when specific signals
arrive
Operating System Concepts Essentials – 2nd Edition
15.31
Silberschatz, Galvin and Gagne ©2013
Processes and Threads
 Linux uses same internal representation for
processes and threads

A thread is simply a new process that happens to
share same address space as parent

Both are called tasks by Linux
 Distinction only made when new thread is created
by clone() system call

fork() creates a new task with its own new task
context

clone() creates a new task with its own identity,
but is allowed to share data structures of its parent
Operating System Concepts Essentials – 2nd Edition
15.32
Silberschatz, Galvin and Gagne ©2013
Processes and Threads
 clone() gives an application fine-grained control
over exactly what is shared between two threads
Operating System Concepts Essentials – 2nd Edition
15.33
Silberschatz, Galvin and Gagne ©2013
Chapter 15: The Linux System
 Linux History
 Design Principles
 Kernel Modules
 Process Management
 Scheduling
Operating System Concepts Essentials – 2nd Edition
15.34
Silberschatz, Galvin and Gagne ©2013
Scheduling
 Job of allocating CPU time to different tasks within
an OS
 In addition to user tasks, scheduling also includes
running various Linux kernel tasks, e.g.,

Tasks requested by a running process

Tasks that execute internally
 E.g.,
Device driver
Operating System Concepts Essentials – 2nd Edition
15.35
Silberschatz, Galvin and Gagne ©2013
Scheduling
 As of 2.5, new scheduling algorithm – preemptive,
priority-based, known as O(1)

Real-time range

Nice value

Had challenges with interactive performance
 2.6 introduced Completely Fair Scheduler (CFS)
Operating System Concepts Essentials – 2nd Edition
15.36
Silberschatz, Galvin and Gagne ©2013
CFS
 Eliminates traditional, common idea of time slice

Instead, all tasks allocated some portion of
processor’s time
 CFS calculates how long process should run as
function of total number of tasks

N runnable tasks means each gets 1/N of
processor’s time
 Each tasked weighted with its nice value

Smaller nice value -> higher weight (higher priority)
Operating System Concepts Essentials – 2nd Edition
15.37
Silberschatz, Galvin and Gagne ©2013
CFS (Cont.)
 Each task’s run time proportional to task’s weight
divided by total weight of all runnable tasks
 Target latency - desired interval during which each
task should run at least once

E.g., 2 runnable tasks with equal weight and target
latency of 10ms – each then runs for 5ms
 If
10 runnable tasks, each runs for 1ms
 Minimum granularity ensures each run has
reasonable amount of time
Operating System Concepts Essentials – 2nd Edition
15.38
Silberschatz, Galvin and Gagne ©2013
Kernel Synchronization
 Request for kernel-mode execution can occur in two
ways:
1.
2.
Running program may request an OS service
 Explicitly
via system call
 Implicitly,
e.g., when a page fault occurs
Device driver may deliver hardware interrupt that
causes CPU to start executing a kernel-defined
handler
 Kernel synchronization requires framework that
allow kernel’s critical sections to run without
interruption by another critical section
Operating System Concepts Essentials – 2nd Edition
15.39
Silberschatz, Galvin and Gagne ©2013
Kernel Synchronization (Cont.)
 Linux uses two techniques to protect critical sections:
1.
Normal kernel code is nonpreemptible (until 2.6)
2.
Second technique applies to critical sections that
occur during in interrupt service routines
Interrupts disabled during critical section

–

kernel can proceed without risk of concurrent access of
shared data structures
Kernel provides spinlocks, semaphores, and readerwriter versions of both

Behavior modified if on single processor or multi:
Operating System Concepts Essentials – 2nd Edition
15.40
Silberschatz, Galvin and Gagne ©2013
Kernel Synchronization (Cont.)
 Linux’s kernel uses a synchronization architecture
that allows long critical sections to run without having
interrupts disabled for critical section’s entire duration
 Interrupt service routines are separated into top half
and bottom half

Top half is normal interrupt service routine; runs with
recursive interrupts disabled

Bottom half is run (with interrupts enabled) by
miniature scheduler that ensures bottom halves never
interrupt themselves
 Architecture has mechanism for disabling selected
bottom halves while executing normal, foreground
kernel code
Operating System Concepts Essentials – 2nd Edition
15.41
Silberschatz, Galvin and Gagne ©2013
Interrupt Protection Levels
 Each level may be interrupted by code running at a
higher level

Never be interrupted by code running at same or lower
level
 User processes can always be preempted by another
process when a time-sharing scheduling interrupt
occurs
Operating System Concepts Essentials – 2nd Edition
15.42
Silberschatz, Galvin and Gagne ©2013
Symmetric Multiprocessing
 Linux 2.0 was first Linux kernel to support SMP

Separate processes or threads can execute in
parallel on separate processors
 Until version 2.2, to preserve kernel’s
nonpreemptible synchronization requirements,
SMP imposes a restriction: only one processor may
execute kernel-mode code at a time

Implemented with a a single kernel spinlock
 Later releases implement more scalability by
splitting single spinlock into multiple locks, each
protecting a small subset of kernel data structures
 Version 3.0 adds more fine-grained locking,
processor affinity, and load-balancing
Operating System Concepts Essentials – 2nd Edition
15.43
Silberschatz, Galvin and Gagne ©2013