II OS Structures
syslab.cse.yzu.edu.tw
2.1 OS Services
• OS services provide functions to help the users
–
–
–
–
–
–
User interface: GUI, CLI, Batch
Program execution: Loading and running code
I/O operations
File-system manipulation
Communications: message passing and shared memory
Error detection
• Other functions for ensuring the efficient operations
– Resource allocation
– Logging
– Protection and security
YZUCSE SYSLAB
czyang@acm.org
CS305 - Operating Systems
2
2.2 User and OS Interfaces
• Command Line Interface (CLI)
– shell
– Terminal
• Graphical User Interface (GUI)
• Touchscreen Interfaces
YZUCSE SYSLAB
czyang@acm.org
CS305 - Operating Systems
3
2.3 System Calls
syslab.cse.yzu.edu.tw
System Calls
• System calls provide a programming interface
to the services provided by the OS.
• The invocation interface of system calls
– syscall (a dedicated instruction in the x86_64
architecture )
• When a system call is invoked, the execution
mode is changed to the kernel mode.
– An example to use write() system call in linux.
– write(1, message, 13)
YZUCSE SYSLAB
czyang@acm.org
CS305 - Operating Systems
5
An example using a system call – hello.s
# ---------------------------------------------------------------------------------------# Writes "Hello, World" to the console using only system calls. Runs on 64-bit Linux only.
# To assemble and run:
# gcc -c hello.s && ld hello.o && ./a.out
# or
# gcc -nostdlib hello.s && ./a.out
# ---------------------------------------------------------------------------------------.global _start
.text
_start:
# write(1, message, 13)
mov $1, %rax
mov $1, %rdi
mov $message, %rsi
mov $13, %rdx
syscall
# exit(0)
mov $60, %rax
xor %rdi, %rdi
syscall
message:
.ascii "Hello, world\n"
YZUCSE SYSLAB
czyang@acm.org
write() is a system call
which will invoke
sys_write() in the OS kernel.
# system call 1 is write()
# file handle 1 is stdout
# address of string to output
# number of bytes
# invoke operating system to do the write
# system call 60 is exit
# we want return code 0
# invoke operating system to exit
http://cs.lmu.edu/~ray/notes/linuxsyscalls/
CS305 - Operating Systems
6
System call implementation
• Typically, a number is associated with each system
call.
– An index table (linux/arch/x86/entry/syscalls/syscall_64.tbl )
# The abi is "common", "64" or "x32" for this file.
#
0
common
read
1
common
write
2
common
open
3
common
close
4
common
stat
5
common
fstat
6
common
lstat
7 …
sys_read
sys_write
sys_open
sys_close
sys_newstat
sys_newfstat
sys_newlstat
• Invocation steps
1. Find the system call from the table
2. Invoke the functions
3. Return status of the system call and any return values
YZUCSE SYSLAB
czyang@acm.org
CS305 - Operating Systems
7
System call operation
YZUCSE SYSLAB
czyang@acm.org
CS305 - Operating Systems
8
System call invocation in Linux
printf("Hello world!“) calls
write(1, buf, size)
mov
mov
mov
mov
syscall
User
Mode
Kernel
Mode
unistd_64.h
sys_write
index table
YZUCSE SYSLAB
czyang@acm.org
User program
$1, %rax
$1, %rdi
$buf, %rsi
$size, %rdx
asmlinkage long sys_write(unsigned int fd, const char __user
*buf, size_t count);
ssize_t ksys_write(unsigned int fd, const char __user *buf,
size_t count)
{
…
}
CS305 - Operating Systems
9
Standard C Library
• A C program invoking printf() library call,
which calls write() system call
YZUCSE SYSLAB
czyang@acm.org
CS305 - Operating Systems
10
Application Program Interface (API)
• People usually design programs via a highlevel Application Program Interface (API)
rather than direct system calls.
• Why use APIs rather than system calls?
– One benefit concerns program portability.
– Actual system calls can often be more detailed
and difficult to work with than the API.
write(1, buf, size)
YZUCSE SYSLAB
czyang@acm.org
vs.
mov
mov
mov
mov
syscall
CS305 - Operating Systems
$1, %rax
$1, %rdi
$buf, %rsi
$size, %rdx
11
Parameter Passing in System Calls
• Three general methods used to pass parameters to
the OS
– Parameters stored in registers
• Constraint of the number of registers
– Parameters stored in a block, or table, in memory, and
address of block passed as a parameter in a register
• Linux uses this approach.
– Parameters placed, or pushed,
onto the stack by the program and
popped off the stack by the OS.
– Block and stack methods do not
limit the number or length of
parameters being passed.
YZUCSE SYSLAB
czyang@acm.org
CS305 - Operating Systems
12
2.5 Linkers and Loaders
• To run a program on a CPU, the program
must be
– brought into memory and
– placed in the context of a process
• The process of running a program involves
– Compilation
– Linking
– Loading
YZUCSE SYSLAB
czyang@acm.org
CS305 - Operating Systems
13
Running a program
• Compilation
– Source files  object files
– The obj files are relocatable.
• They can be loaded into any physical
memory space.
• Linking
– Relocatable obj files + libraries
 exec. file
– Resolving external references
• Loading
– Load the executable file into
memory
– Relocation
YZUCSE SYSLAB
czyang@acm.org
CS305 - Operating Systems
14
2.6 Why Applications Are OS-specific?
• Fundamentally, applications compiled on one
operating system are not executable on other
operating systems.
• Why?
– Each OS provides a unique set of system calls.
• Challenges at the application level
– APIs are different.
• Challenges at lower levels
– Each OS has a binary format for applications.
– CPUs have varying instruction sets, and only applications
containing the appropriate instructions can execute correctly.
– The system calls vary among OSs in many respects.
YZUCSE SYSLAB
czyang@acm.org
CS305 - Operating Systems
15
Running on multiple operating
systems
• Three possible ways to run applications on multiple
operating systems
1.
2.
The application can be written in an interpreted language (such as
Python or Ruby).
The application can be written in a language that includes a virtual
machine containing the running application.
• This RTE (run-time environment) has been ported, or developed, for
many operating systems.
3.
The application developer can use a standard language or API in
which the compiler generates binaries in a machine- and
operating-system specific language.
• The application must be ported to each operating system on which it
will run.
YZUCSE SYSLAB
czyang@acm.org
CS305 - Operating Systems
16
2.7 OS Design and Implementation
• Design and Implementation of an OS is not
“solvable”, but some approaches have proved
successful.
• The first problem in designing a system is to define
goals and specifications.
• User goals and System goals
– User goals – operating system should be convenient to use,
easy to learn, reliable, safe, and fast
– System goals – operating system should be easy to design,
implement, and maintain, as well as flexible, reliable, errorfree, and efficient
• There is, in short, no unique solution to the problem
of defining the requirements for an OS.
YZUCSE SYSLAB
czyang@acm.org
CS305 - Operating Systems
17
Policy vs. Mechanism
• An important principle to separate
– Policy: What will be done?
– Mechanism: How to do it?
• Policies decide what will be done.
• Mechanisms determine how to do something.
– The separation allows maximum flexibility if policy
decisions are to be changed later.
YZUCSE SYSLAB
czyang@acm.org
CS305 - Operating Systems
18
Implementation Issues
• Once an OS is designed, it is usually implemented in
a mix of languages.
– The lowest levels of the kernel: Assembly and C
– Higher-level routines: C and C++
– System libraries: C++ or even higher-level languages
• The advantages of using a higher-level language
– The code can be written faster, is more compact, and is
easier to understand and debug.
– Improvements in compiler technology will improve the
generated code for the entire OS by simple recompilation.
– Finally, an OS is far easier to port to other hardware.
YZUCSE SYSLAB
czyang@acm.org
CS305 - Operating Systems
19
2.8 OS Structure
• Various ways to structure the OS as follows
–
–
–
–
–
–
YZUCSE SYSLAB
czyang@acm.org
Simple structure – MS-DOS
Monolithic structure – UNIX
Layered structure – an abstraction
Microkernel – Mach
Modules
Hybrid systems
CS305 - Operating Systems
20
1. Simple Structure
• MS-DOS
– Written to provide the
most functionality in the
least space
– Not divided into modules
– Although MS-DOS has
some structure, its
interfaces and levels of
functionality are not well
separated
YZUCSE SYSLAB
czyang@acm.org
CS305 - Operating Systems
21
2. Monolithic Structure
• Place all of the functionality of the kernel into a
single, static binary file that runs in a single address
space.
• An example of such limited
structuring is the original UNIX.
• Despite the apparent simplicity
of monolithic kernels, they are
difficult to implement and
extend.
https://pbs.twimg.com/media/EEBvmJHU8AA0_qA.jpg
https://www.newton.com.tw/img/c/5f3/cGcq5iZmhTM2MjNmBjZ4cjZ0IGM3YmYjVDNxcjYmJGNmBDNhZWYhVjMwMDOv0WZ0l2LjlGcvU2apFmYv02bj5SdklWYi5yYyN3Ztl2LvoDc0RHa.jpg
YZUCSE SYSLAB
czyang@acm.org
CS305 - Operating Systems
22
3. Layered Approach
• 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
YZUCSE SYSLAB
czyang@acm.org
CS305 - Operating Systems
23
4. Microkernels
• Microkernels were a very hot topic in the 1980s.
• It moves as much from the kernel into “user” space
• Communication takes place between user modules
using message passing
– The client program and service interact by exchanging
messages with the microkernel.
YZUCSE SYSLAB
czyang@acm.org
CS305 - Operating Systems
24
Pros and cons
• Benefits:
– Easier to extend a microkernel
– Easier to port the operating system to new architectures
– More security and reliability
• Most services are running as user—rather than kernel—processes.
• If a service fails, the rest of the operating system remains untouched.
• Detriments:
– Performance can suffer
• Increased system-function overhead of user space to kernel space
communication
• In addition, the operating system may have to switch from one process
to the next to exchange the messages.
YZUCSE SYSLAB
czyang@acm.org
CS305 - Operating Systems
25
5. Modules
• Perhaps the best current methodology for OS design
involves using loadable kernel modules (LKMs).
• Here, the kernel has a set of core components and
can link in additional services via modules.
• Overall, similar to layers but with more flexibility.
https://www.researchgate.net/profile/Ilja-Zakharov/publication/299373758/figure/fig1/AS:669947386687511@1536739312603/Interaction-of-Linuxkernel-modules-with-their-environment.png
YZUCSE SYSLAB
czyang@acm.org
CS305 - Operating Systems
26
6. Hybrid Systems
• Most modern operating systems actually not one
pure model
– Hybrid combines multiple approaches to address
performance, security, usability needs
– Linux and Solaris kernels in kernel address space, so
monolithic, plus modular for dynamic loading of functionality
– Windows mostly monolithic, plus microkernel for different
subsystem personalities
YZUCSE SYSLAB
czyang@acm.org
CS305 - Operating Systems
27
Example: macOS and iOS
• Layers
–
–
–
–
YZUCSE SYSLAB
czyang@acm.org
User experience layer
Application framework layer
Core frameworks
Kernel environment
CS305 - Operating Systems
28
Android Architecture
YZUCSE SYSLAB
czyang@acm.org
CS305 - Operating Systems
29
2.10 OS Debugging
• Debugging is to find and fix errors, or bugs.
• Ways to get error information
– OSs generate log files containing error
information
– Failure of an application can generate core dump
file capturing memory of the process
– Operating system failure can generate crash
dump file containing kernel memory
YZUCSE SYSLAB
czyang@acm.org
CS305 - Operating Systems
30
Performance Monitoring and Tuning
• Beyond crashes, performance tuning can
optimize system performance
– Sometimes using trace listings of activities,
recorded for analysis
– Profiling is periodic sampling of instruction pointer
to look for statistical trends
• Kernighan’s Law
– Debugging is twice as hard as writing the code in
the first place. Therefore, if you write the code as
cleverly as possible, you are, by definition, not
smart enough to debug it.
YZUCSE SYSLAB
czyang@acm.org
CS305 - Operating Systems
31
System counters
• Operating systems keep track of system activity through a series
of counters.
• For example, top in Linux
https://linoxide.com/linux-top-command-examples-screenshots/
YZUCSE SYSLAB
czyang@acm.org
CS305 - Operating Systems
32
Q&A
syslab.cse.yzu.edu.tw