Outline

▪ Operating System Services

▪ User and Operating System-Interface
Chapter 2: Operating-System ▪ System Calls
▪ System Services
Services ▪ Linkers and Loaders
▪ Why Applications are Operating System Specific
▪ Design and Implementation
▪ Operating System Structure
▪ Building and Booting an Operating System
▪ Operating System Debugging

Operating System Concepts – 10th Edition Silberschatz, Galvin and Gagne ©2018 Operating System Concepts – 10th Edition 2.2 Silberschatz, Galvin and Gagne ©2018

Objectives Operating System Services

▪ Identify services provided by an operating system ▪ Operating systems provide an environment for execution of programs and
services to programs and users
▪ Illustrate how system calls are used to provide operating system
services
▪ One set of operating-system services provides functions that are helpful to the
user:
▪ Compare and contrast monolithic, layered, microkernel, modular,
and hybrid strategies for designing operating systems
• User interface - Almost all operating systems have a user interface (UI).
Varies between Command-Line (CLI), Graphics User Interface
▪ Illustrate the process for booting an operating system
4
(GUI), touch-screen, Batch
▪ Apply tools for monitoring operating system performance
• Program execution - The system must be able to load a program into
▪ Design and implement kernel modules for interacting with a Linux memory and to run that program, end execution, either normally or
kernel abnormally (indicating error)
• I/O operations - A running program may require I/O, which may
involve a file or an I/O device
• File-system manipulation - The file system is of particular interest.
Programs need to read and write files and directories, create and delete
them, search them, list file Information, permission management.

Operating System Concepts – 10th Edition 2.3 Silberschatz, Galvin and Gagne ©2018 Operating System Concepts – 10th Edition 2.4 Silberschatz, Galvin and Gagne ©2018
 Operating System Services (Cont.) Operating System Services (Cont.)
▪ One set of operating-system services provides functions that are helpful to the ▪ Another set of OS functions exists for ensuring the efficient operation of the
user (Cont.): system itself via resource sharing
• Communications – Processes may exchange information, on the same • Resource allocation - When multiple users or multiple jobs running
computer or between computers over a network concurrently, resources must be allocated to each of them
4 Many types of resources - CPU cycles, main memory, file storage,
4 Communications may be via shared memory or through message
I/O devices.
passing (packets moved by the OS)
• Logging - To keep track of which users use how much and what kinds of
• Error detection – OS needs to be constantly aware of possible errors computer resources
4 May occur in the CPU and memory hardware, in I/O devices, in user • Protection and security - The owners of information stored in a
program multiuser or networked computer system may want to control use of that
4 For each type of error, OS should take the appropriate action to information, concurrent processes should not interfere with each other
ensure correct and consistent computing 4 Protection involves ensuring that all access to system resources is
controlled
4 Debugging facilities can greatly enhance the user’s and programmer’s
abilities to efficiently use the system 4 Security of the system from outsiders requires user authentication,
extends to defending external I/O devices from invalid access attempts

Operating System Concepts – 10th Edition 2.5 Silberschatz, Galvin and Gagne ©2018 Operating System Concepts – 10th Edition 2.6 Silberschatz, Galvin and Gagne ©2018

A View of Operating System Services Command Line interpreter

▪ CLI allows direct command entry

▪ Sometimes implemented in kernel, sometimes by systems
program
▪ Sometimes multiple flavors implemented – shells
▪ Primarily fetches a command from user and executes it
▪ Sometimes commands built-in, sometimes just names of
programs
• If the latter, adding new features doesn’t require shell
modification

Operating System Concepts – 10th Edition 2.7 Silberschatz, Galvin and Gagne ©2018 Operating System Concepts – 10th Edition 2.8 Silberschatz, Galvin and Gagne ©2018
 Bourne Shell Command Interpreter User Operating System Interface - GUI

▪ User-friendly desktop metaphor interface

• Usually mouse, keyboard, and monitor
• Icons represent files, programs, actions, etc
• Various mouse buttons over objects in the interface cause various actions
(provide information, options, execute function, open directory (known as
a folder)
• Invented at Xerox PARC
▪ Many systems now include both CLI and GUI interfaces
• Microsoft Windows is GUI with CLI “command” shell
• Apple Mac OS X is “Aqua” GUI interface with UNIX kernel underneath
and shells available
• Unix and Linux have CLI with optional GUI interfaces (CDE, KDE,
GNOME)

Operating System Concepts – 10th Edition 2.9 Silberschatz, Galvin and Gagne ©2018 Operating System Concepts – 10th Edition 2.10 Silberschatz, Galvin and Gagne ©2018

Touchscreen Interfaces The Mac OS X GUI

▪ Touchscreen devices require new

interfaces
• Mouse not possible or not desired
• Actions and selection based on
gestures
• Virtual keyboard for text entry
▪ Voice commands

Operating System Concepts – 10th Edition 2.11 Silberschatz, Galvin and Gagne ©2018 Operating System Concepts – 10th Edition 2.12 Silberschatz, Galvin and Gagne ©2018
 System Calls Example of System Calls

▪ System call sequence to copy the contents of one file to another file
▪ Programming interface to the services provided by the OS
▪ Typically written in a high-level language (C or C++)
▪ Mostly accessed by programs via a high-level Application Programming
Interface (API) rather than direct system call use
▪ Three most common APIs are Win32 API for Windows, POSIX API for
POSIX-based systems (including virtually all versions of UNIX, Linux, and
Mac OS X), and Java API for the Java virtual machine (JVM)
Note that the system-call names used throughout this text are generic

Operating System Concepts – 10th Edition 2.13 Silberschatz, Galvin and Gagne ©2018 Operating System Concepts – 10th Edition 2.14 Silberschatz, Galvin and Gagne ©2018

Example of Standard API System Call Implementation

▪ Typically, a number is associated with each system call

• System-call interface maintains a table indexed according to these
numbers
▪ The system call interface invokes the intended system call in OS kernel and
returns status of the system call and any return values
▪ The caller need know nothing about how the system call is implemented
• Just needs to obey API and understand what OS will do as a result call
• Most details of OS interface hidden from programmer by API
4 Managed by run-time support library (set of functions built into
libraries included with compiler)

Operating System Concepts – 10th Edition 2.15 Silberschatz, Galvin and Gagne ©2018 Operating System Concepts – 10th Edition 2.16 Silberschatz, Galvin and Gagne ©2018
 API – System Call – OS Relationship System Call Parameter Passing

▪ Often, more information is required than simply identity of desired system

call
• Exact type and amount of information vary according to OS and call
▪ Three general methods used to pass parameters to the OS
• Simplest: pass the parameters in registers
4 In some cases, may be more parameters than registers
• Parameters stored in a block, or table, in memory, and address of block
passed as a parameter in a register
4 This approach taken by Linux and Solaris

• Parameters placed, or pushed, onto the stack by the program and

popped off the stack by the operating system
• Block and stack methods do not limit the number or length of parameters
being passed

Operating System Concepts – 10th Edition 2.17 Silberschatz, Galvin and Gagne ©2018 Operating System Concepts – 10th Edition 2.18 Silberschatz, Galvin and Gagne ©2018

Parameter Passing via Table Types of System Calls

▪ Process control
• create process, terminate process
• end, abort
• load, execute
• get process attributes, set process attributes
• wait for time
• wait event, signal event
• allocate and free memory
• Dump memory if error
• Debugger for determining bugs, single step execution
• Locks for managing access to shared data between processes

Operating System Concepts – 10th Edition 2.19 Silberschatz, Galvin and Gagne ©2018 Operating System Concepts – 10th Edition 2.20 Silberschatz, Galvin and Gagne ©2018
 Types of System Calls (Cont.) Types of System Calls (Cont.)

▪ File management ▪ Information maintenance

• create file, delete file • get time or date, set time or date
• open, close file • get system data, set system data
• read, write, reposition • get and set process, file, or device attributes
• get and set file attributes ▪ Communications
▪ Device management • create, delete communication connection
• request device, release device • send, receive messages if message passing model to host
• read, write, reposition name or process name
4 From client to server
• get device attributes, set device attributes
• Shared-memory model create and gain access to memory
• logically attach or detach devices
regions
• transfer status information
• attach and detach remote devices

Operating System Concepts – 10th Edition 2.21 Silberschatz, Galvin and Gagne ©2018 Operating System Concepts – 10th Edition 2.22 Silberschatz, Galvin and Gagne ©2018

Types of System Calls (Cont.) Examples of Windows and Unix System Calls

▪ Protection
• Control access to resources
• Get and set permissions
• Allow and deny user access

Operating System Concepts – 10th Edition 2.23 Silberschatz, Galvin and Gagne ©2018 Operating System Concepts – 10th Edition 2.24 Silberschatz, Galvin and Gagne ©2018
 Standard C Library Example Example: Arduino
▪ C program invoking printf() library call, which calls write() system call ▪ Single-tasking
▪ No operating system
▪ Programs (sketch) loaded via
USB into flash memory
▪ Single memory space
▪ Boot loader loads program
▪ Program exit -> shell reloaded

At system startup running a program

Operating System Concepts – 10th Edition 2.25 Silberschatz, Galvin and Gagne ©2018 Operating System Concepts – 10th Edition 2.26 Silberschatz, Galvin and Gagne ©2018

Example: FreeBSD System Services

▪ Unix variant ▪ System programs provide a convenient environment for program development
▪ Multitasking and execution. They can be divided into:

▪ User login -> invoke user’s choice of shell • File manipulation

▪ Shell executes fork() system call to create • Status information sometimes stored in a file
process • Programming language support
• Executes exec() to load program into • Program loading and execution
process • Communications
• Shell waits for process to terminate or • Background services
continues with user commands
• Application programs
▪ Process exits with:
▪ Most users’ view of the operating system is defined by system programs, not
• code = 0 – no error the actual system calls
• code > 0 – error code

Operating System Concepts – 10th Edition 2.27 Silberschatz, Galvin and Gagne ©2018 Operating System Concepts – 10th Edition 2.28 Silberschatz, Galvin and Gagne ©2018
 System Services (Cont.) System Services (Cont.)
▪ Provide a convenient environment for program development and ▪ File modification
execution
• Text editors to create and modify files
• Some of them are simply user interfaces to system calls; others are
considerably more complex • Special commands to search contents of files or perform transformations
of the text
▪ File management - Create, delete, copy, rename, print, dump, list, and ▪ Programming-language support - Compilers, assemblers, debuggers and
generally manipulate files and directories interpreters sometimes provided

▪ Status information ▪ Program loading and execution- Absolute loaders, relocatable loaders,
linkage editors, and overlay-loaders, debugging systems for higher-level and
• Some ask the system for info - date, time, amount of available machine language
memory, disk space, number of users
▪ Communications - Provide the mechanism for creating virtual connections
• Others provide detailed performance, logging, and debugging among processes, users, and computer systems
information
• Allow users to send messages to one another’s screens, browse web
• Typically, these programs format and print the output to the terminal pages, send electronic-mail messages, log in remotely, transfer files from
or other output devices one machine to another
• Some systems implement a registry - used to store and retrieve
configuration information

Operating System Concepts – 10th Edition 2.29 Silberschatz, Galvin and Gagne ©2018 Operating System Concepts – 10th Edition 2.30 Silberschatz, Galvin and Gagne ©2018

System Services (Cont.) Linkers and Loaders

▪ Background Services
▪ Source code compiled into object files designed to be loaded into any physical
• Launch at boot time memory location – relocatable object file
Some for system startup, then terminate
4
▪ Linker combines these into single binary executable file
4 Some from system boot to shutdown
• Also brings in libraries
• Provide facilities like disk checking, process scheduling, error logging,
printing ▪ Program resides on secondary storage as binary executable
• Run in user context not kernel context ▪ Must be brought into memory by loader to be executed
• Known as services, subsystems, daemons • Relocation assigns final addresses to program parts and adjusts code
and data in program to match those addresses
▪ Application programs
▪ Modern general purpose systems don’t link libraries into executables
• Don’t pertain to system
• Rather, dynamically linked libraries (in Windows, DLLs) are loaded
• Run by users
as needed, shared by all that use the same version of that same library
• Not typically considered part of OS (loaded once)
• Launched by command line, mouse click, finger poke ▪ Object, executable files have standard formats, so operating system knows
how to load and start them

Operating System Concepts – 10th Edition 2.31 Silberschatz, Galvin and Gagne ©2018 Operating System Concepts – 10th Edition 2.32 Silberschatz, Galvin and Gagne ©2018
 The Role of the Linker and Loader Why Applications are Operating System Specific

▪ Apps compiled on one system usually not executable on other operating

systems
▪ Each operating system provides its own unique system calls
• Own file formats, etc.
▪ Apps can be multi-operating system
• Written in interpreted language like Python, Ruby, and interpreter
available on multiple operating systems
• App written in language that includes a VM containing the running app
(like Java)
• Use standard language (like C), compile separately on each operating
system to run on each
▪ Application Binary Interface (ABI) is architecture equivalent of API,
defines how different components of binary code can interface for a given
operating system on a given architecture, CPU, etc.

Operating System Concepts – 10th Edition 2.33 Silberschatz, Galvin and Gagne ©2018 Operating System Concepts – 10th Edition 2.34 Silberschatz, Galvin and Gagne ©2018

Design and Implementation Policy and Mechanism

▪ Design and Implementation of OS is not “solvable”, but some approaches ▪ Policy: What needs to be done?
have proven successful • Example: Interrupt after every 100 seconds
▪ Internal structure of different Operating Systems can vary widely ▪ Mechanism: How to do something?
▪ Start the design by defining goals and specifications • Example: timer
▪ Affected by choice of hardware, type of system ▪ Important principle: separate policy from mechanism
▪ User goals and System goals ▪ The separation of policy from mechanism is a very important
• User goals – operating system should be convenient to use, easy to principle, it allows maximum flexibility if policy decisions are
learn, reliable, safe, and fast to be changed later.
• System goals – operating system should be easy to design, implement, • Example: change 100 to 200
and maintain, as well as flexible, reliable, error-free, and efficient
▪ Specifying and designing an OS is highly creative task of software
engineering

Operating System Concepts – 10th Edition 2.35 Silberschatz, Galvin and Gagne ©2018 Operating System Concepts – 10th Edition 2.36 Silberschatz, Galvin and Gagne ©2018
 Implementation Operating System Structure
▪ Much variation
▪ General-purpose OS is very large program
• Early OSes in assembly language
▪ Various ways to structure ones
• Then system programming languages like Algol, PL/1
• Simple structure – MS-DOS
• Now C, C++
• More complex – UNIX
▪ Actually usually a mix of languages
• Layered – an abstraction
• Lowest levels in assembly
• Microkernel – Mach
• Main body in C
• Systems programs in C, C++, scripting languages like PERL, Python,
shell scripts
▪ More high-level language easier to port to other hardware
• But slower
▪ Emulation can allow an OS to run on non-native hardware

Operating System Concepts – 10th Edition 2.37 Silberschatz, Galvin and Gagne ©2018 Operating System Concepts – 10th Edition 2.38 Silberschatz, Galvin and Gagne ©2018

Monolithic Structure – Original UNIX Traditional UNIX System Structure

▪ UNIX – limited by hardware functionality, the original UNIX operating Beyond simple but not fully layered
system had limited structuring.
▪ The UNIX OS consists of two separable parts
• Systems programs
• The kernel
4 Consists of everything below the system-call interface and above the
physical hardware
4 Provides the file system, CPU scheduling, memory management, and
other operating-system functions; a large number of functions for one
level

Operating System Concepts – 10th Edition 2.39 Silberschatz, Galvin and Gagne ©2018 Operating System Concepts – 10th Edition 2.40 Silberschatz, Galvin and Gagne ©2018
 Linux System Structure Layered Approach
Monolithic plus modular design
▪ The operating system is divided
into a number of layers (levels),
each built on top of lower layers.
The bottom layer (layer 0), is the
hardware; the highest (layer N) is
the user interface.
▪ With modularity, layers are
selected such that each uses
functions (operations) and services
of only lower-level layers

Operating System Concepts – 10th Edition 2.41 Silberschatz, Galvin and Gagne ©2018 Operating System Concepts – 10th Edition 2.42 Silberschatz, Galvin and Gagne ©2018

Microkernels Microkernel System Structure

▪ Moves as much from the kernel into user space
▪ Mach is an example of microkernel
• Mac OS X kernel (Darwin) partly based on Mach
▪ Communication takes place between user modules using message
passing
▪ Benefits:
• Easier to extend a microkernel
• Easier to port the operating system to new architectures
• More reliable (less code is running in kernel mode)
• More secure
▪ Detriments:
• Performance overhead of user space to kernel space communication

Operating System Concepts – 10th Edition 2.43 Silberschatz, Galvin and Gagne ©2018 Operating System Concepts – 10th Edition 2.44 Silberschatz, Galvin and Gagne ©2018
 Building and Booting an Operating System Building and Booting Linux

▪ Operating systems generally designed to run on a class of systems with ▪ Download Linux source code (http://www.kernel.org)
variety of peripherals
▪ Configure kernel via “make menuconfig”
▪ Commonly, operating system already installed on purchased computer
▪ Compile the kernel using “make”
• But can build and install some other operating systems
• Produces vmlinuz, the kernel image
• If generating an operating system from scratch
• Compile kernel modules via “make modules”
4 Write the operating system source code
• Install kernel modules into vmlinuz via “make
4 Configure the operating system for the system on which it will run
modules_install”
4 Compile the operating system
• Install new kernel on the system via “make install”
4 Install the operating system
4 Boot the computer and its new operating system

Operating System Concepts – 10th Edition 2.45 Silberschatz, Galvin and Gagne ©2018 Operating System Concepts – 10th Edition 2.46 Silberschatz, Galvin and Gagne ©2018

System Boot Operating-System Debugging

▪ When power initialized on system, execution starts at a fixed memory
location ▪ Debugging is finding and fixing errors, or bugs
▪ Operating system must be made available to hardware so hardware can start ▪ Also performance tuning
it ▪ OS generate log files containing error information
• Small piece of code – bootstrap loader, BIOS, stored in ROM or ▪ Failure of an application can generate core dump file capturing memory of
EEPROM locates the kernel, loads it into memory, and starts it the process
• Sometimes two-step process where boot block at fixed location loaded ▪ Operating system failure can generate crash dump file containing kernel
by ROM code, which loads bootstrap loader from disk memory
• Modern systems replace BIOS with Unified Extensible Firmware ▪ Beyond crashes, performance tuning can optimize system performance
Interface (UEFI)
• Sometimes using trace listings of activities, recorded for analysis
▪ Common bootstrap loader, GRUB, allows selection of kernel from multiple
• Profiling is periodic sampling of instruction pointer to look for statistical
disks, versions, kernel options
trends
▪ Kernel loads and system is then running Kernighan’s Law: “Debugging is twice as hard as writing the code in the first
▪ Boot loaders frequently allow various boot states, such as single user mode place. Therefore, if you write the code as cleverly as possible, you are, by
definition, not smart enough to debug it.”

Operating System Concepts – 10th Edition 2.47 Silberschatz, Galvin and Gagne ©2018 Operating System Concepts – 10th Edition 2.48 Silberschatz, Galvin and Gagne ©2018
 Performance Tuning Tracing
▪ Collects data for a specific event, such as steps involved in a
▪ Improve performance by removing bottlenecks
system call invocation
▪ OS must provide means of computing and displaying measures of system
▪ Tools include
behavior
• strace – trace system calls invoked by a process
▪ For example, “top” program or Windows Task Manager
• gdb – source-level debugger
• perf – collection of Linux performance tools
• tcpdump – collects network packets

Operating System Concepts – 10th Edition 2.49 Silberschatz, Galvin and Gagne ©2018 Operating System Concepts – 10th Edition 2.50 Silberschatz, Galvin and Gagne ©2018

BCC Linux bcc/BPF Tracing Tools

▪ Debugging interactions between user-level and kernel code nearly impossible

without toolset that understands both and an instrument their actions
▪ BCC (BPF Compiler Collection) is a rich toolkit providing tracing features for
Linux
• See also the original DTrace
▪ For example, disksnoop.py traces disk I/O activity

▪ Many other tools (next slide)

Operating System Concepts – 10th Edition 2.51 Silberschatz, Galvin and Gagne ©2018 Operating System Concepts – 10th Edition 2.52 Silberschatz, Galvin and Gagne ©2018
 End of Chapter 2

Operating System Concepts – 10th Edition Silberschatz, Galvin and Gagne ©2018