COMP0312 Operating Systems 2025 Spring Semester

COMP0312 운영체제 004분반

CH2 OS Structures

2025년 3월 11일
IT대학5호관(IT융복합관) 348호
 COMP0312 Operating Systems 2025 Spring Semester

Operating System Services

• OS provides an environment for the execution of programs.
• OS provides services to programs and to the users.
▪ User interface
OS ▪ Program execution User and other system programs
Services ▪ I/O operations
for User ▪ File-system manipulation command
GUI touch screen
Support line (CLI)
▪ Communications user interfaces
▪ Error detection
System calls
OS
Services ▪ Resource Allocation Program
Execution
I/O
Operations
File
Systems
Communicatio
n
for ▪ Logging Resource Accounting Error Protection
Efficient Allocation (via logging) Detection & Security
Operation
▪ Protection and security
services
Operating system

Hardware
 COMP0312 Operating Systems 2025 Spring Semester

User and OS Interfaces

• Command Interpreter (Command-line
Interface: CLI)
▪ Also called “shell”: sh, ksh, csh, bash
▪ Main goal: To receive and execute the next user-
specified command
► Shell has built-in commands
► Shell can execute system programs

• GUI (Graphical User Interface)

▪ mouse, folder, icons, touch screen … etc.

• Touch-screen Interface
 COMP0312 Operating Systems 2025 Spring Semester

System Calls
• System calls: Interface to OS services in the form of routines (library functions or APIs)
• Example of how system calls are used:
file names?
▪ Suppose a cp program that reads data from one file and
copy to another file abc.txt, def.txt

► Request user for two file names

→ prompt user to enter: write a message to screen
〮 Each character being typed is displayed
→ In GUI, icons are shown and user selects the source file
→ Read user input Open files

► Open two files

→ On error, error messages are printed and it terminates
→ Errors: file does not exist, permission error … copy

► Copy(read) data and write to the destination file in a loop

► Close both files
► Write completion message
► Terminate the program Done!!
Write message
 COMP0312 Operating Systems 2025 Spring Semester

Application Programming Interface (API)

• API: A set of functions that are available to an application programmer +
parameter list and type + return value type

▪ Windows API, POSIX API (libc), Java API

► libc: c library for UNIX/Linux environment libc system call
printf write
▪ API can be built on top of other API
write fsync
► Java APIs use libc internally
fread read
▪ API (may or may not) invoke one ore more system calls read mmap
• Why use APIs instead of system calls? malloc brk
memcpy
▪ Program portability strlen
▪ System calls are detailed and difficult to use
 COMP0312 Operating Systems 2025 Spring Semester

System Call Interface

• System call interface
▪ A link to system call routines in OS
▪ A mechanism that intercepts system call invocations of applications,
executes the OS system call routines and returns the return value

user application • Caller does not need to know how

return value
system call is implemented
open()
user
mode
• Caller needs to know only the interface
system call interface and what it returns
kernel
system call function pointers NAME
mode
read - read from a file descriptor
sys_open() { SYNOPSIS
code for open() #include <unistd.h>
return; }
ssize_t read(int fd, void *buf, size_t count);
 COMP0312 Operating Systems 2025 Spring Semester

Sample System Calls

 COMP0312 Operating Systems 2025 Spring Semester

Types of System Calls

• Six major categories Windows system calls
▪ Process control CreateProcess, ExitProcess,
► fork, exec, exit, wait … WaitForSingleObject
▪ File manipulation CreateFile, ReadFile, WriteFile, CloseHandle
► create, open, close, read, write, lseek
▪ Device manipulation SetConsoleMode, ReadConsole,
► open, close, read, write, ioctl WriteConsole
▪ Information maintenance
GetCurrentProcessID, SetTimer, Sleep
► time, date, getpid, alarm, sleep
▪ Communications CreatePipe, CreateFileMapping,
► open, close, connect, accept, read, write, MapViewOfFile
send, recv, pipe, mmap, sendfile …
▪ Protection SetFileSecurity, InitializeSecurityDescriptor,
► Chmod, umask, chown … SetSecurityDescriptorGroup
 COMP0312 Operating Systems 2025 Spring Semester

System Services and Applications

• System services (programs) = System utilities
▪ File management: ls, tar, cp, touch, mv, cp, mkdir, rmdir, find, ln, chown,
chmod, which …
▪ Status information: top, sar, iostat, vmstat, netstat, mpstat, , free …
▪ File modification: text editors
▪ Programming language support: gcc, g++, python, perl …
▪ Program loading and execution: systemctl, ld, nm, readelf …
▪ Communications: curl, wget, wput, ip, ifconfig, telnet, ssh …
▪ Background services: ftpd, dhcpd, httpd, smtpd, xinetd, sshd, smbd,
nfsd, crond, syslogd, ntpd …
• Application programs
▪ Web browsers, text editor, spreadsheet, database, compilers, plotting,
statistics package …
 COMP0312 Operating Systems 2025 Spring Semester

OS Design and Implementation

• Design goals: Requirements can be divided into two
▪ User goals
► ease of use, reliable, ease of learning, fast
▪ System goals
► ease of implementation, ease of maintenance, ease of operation, flexible, efficient,
fault-tolerant
→ Vague requirements and no clear solution
• Guideline: Mechanism and Policy
▪ Separation of policy from mechanisms
► mechanisms: how
► policy: what
▪ It is a technique frequently applied to many cases
► ex) timer mechanisms and scheduling policy
► ex) password expires in 30 days
▪ Why separate them? Policy changes.
► If policy change requires mechanisms change, it is not desirable.
 COMP0312 Operating Systems 2025 Spring Semester

OS Implementation
• Implementing in assembly language
▪ tedious, difficult, error-prone, difficult to port
• Implementing in high-level language
▪ Advantages
► Faster implementation time
► Compact and easier to understand/debug
► Improved complier will improve the generated code
► Easier to port
→ Linux is mostly in C, no need to emulate, runs natively
▪ Disadvantages
► Performance: potentially sub-optimal code generation
→ Not true in today’s compiler technology
→ complier is better at handling complex dependencies
► Compromise
→ small critical code can be first written in high-level language and later replaced with the
optimized ones
 COMP0312 Operating Systems 2025 Spring Semester

Operating System Structure

• Monolithic structure vs. componentized,
modularized approach
▪ component(module): well-defined portion of
system with inputs, outputs and functions
▪ Traditional UNIX and Linux structure
• How did this happen?
▪ Started simple and grew to become out-of-
control Traditional UNIX system structure
► MS-DOS: applications can directly access I/O
► Original UNIX (somewhat layered)
• Monolithic OS is difficult to implement and extend
• Very little overhead in the system call interface
• Communication within the kernel is fast → high speed and high efficiency
 COMP0312 Operating Systems 2025 Spring Semester

OS Structure – Layered Approach

• Layered approach
▪ OS is broken into a number of layers
► bottom layer: layer 0 = hardware
► Layer M = user interface
▪ Layer M invokes operations of layer M-1
▪ Layer M provides operations that can be
called by layer M+1

• Advantage
▪ simplicity → easy to debug and verify system
► nth layer can be debugged without worrying about layers above and assuming n-1th layer is
correct
• Disadvantage
▪ Defining (the functionalities of) layers is difficult
▪ Less efficient
► Crossing layers may add overhead
 COMP0312 Operating Systems 2025 Spring Semester

Microkernels
• Approach
▪ Reduction of complexity (Smaller kernel) -
Let’s structure OS by removing all
nonessential components from the kernel and
implement them as user-level programs that
reside in separate address spaces.
► Which service (component) should remain in the
kernel?
• Microkernel
▪ Main function is to provide communication
between programs and services via message
passing

• Advantages • Disadvantages
▪ Extending OS is easier ▪ Potential performance impact due to increased
► No modification to the kernel communication overhead
► Even the kernel change is small ► Messages need to be copied between services
▪ Easy to port ▪ Overhead from switching of processes
▪ More secure and reliable