OS and Unix Overview
CSci4061: Introduction to Operating Systems
September 9, 2021
Computer Science & Engineering, University of Minnesota
1
Some announcements
• Another TA: , Lab 24
•
• 11:00am-noon Fridays
• Per the department, facial shield in not considered a mask • In-class quizzes: Kahoot!
• Need a permission number?
• Contact for permission numbers
• Lab sections have limited seats; cannot enroll more students in closed sections
unless someone drop
• You must test your projects on CSELabs machines
• Make sure you can access, especially remote access
2
Textbook access
• Temporary access: https://cs.uwec.edu/~tan/priv/www-docs/cs462/USP.pdf
3
Agenda
• OS Evolution • OS Overview • UNIX Overview
4
OS Evolution
Operating system evolution
The evolution of OS depends on:
• Hardware and technology
• To better utilize hardware resources
• Users’ needs
• To improve use efficiency, security, etc.
• New scenarios
• IoT, realtime systems, automotive, etc.
5
Gen 1: Mono-programming (1945-55)
• Large computers (building-size)
• A computer is located in multiple rooms: reader, executer, and printer
• Direct programming of hardware
• User interface was switches and lights (error indicator) • Basically no OS!
• OS is just runtime libraries
6
Gen 2: Batch systems (1955-65)
• Programmers submit multiple jobs
• Stack of punch cards
• Programs were batched
• Same type of jobs batch together
• Load jobs, run them, output results
• OS did some elementary job scheduling • Problems
• Utilization is low: still only one job at a time (serial processing) • No concurrency!
• Users had to wait
7
Gen 3: Multi-programming (1965-80)
• Multiple programs executing in parallel • Allow more efficient use of CPU and I/O
• CPU is still working while waiting for I/O, and vice versa
• Fast time-multiplexing between multiple jobs
• Many people use the same machine at the same time • OS performs resource management and control
• Unix appeared
• and
• Originally in assembly, rewritten in C
8
Gen 4: Personal computers (1980-)
• Examples: DOS, Windows, MacOS, Linux, FreeBSD
• Started as single-user systems
• Evolved into multi-user, multi-programming, and time-sharing systems • Main focus: Ease of use
• Computers are cheap, people expensive
• Evolution of GUIs
• OS provides simple abstractions and resource management
9
Gen 5: Distributed systems (1985-)
• It’s all about connectivity
• Multiple computers linked by a network/bus
• Various flavors:
• Multiprocessor systems
• Client-server systems
• Peer-to-peer systems and Grids • Cloud computing
• Better resource sharing and fault tolerance • Networked applications drive everything
• Web, email, messaging, social networks, etc.
10
Gen 6: Mobile computing (2000-)
• Portability
• Examples: Google Android, Apple iOS
• Handheld and wearable devices: smart phones, tablets, watches, . . . • Main constraints: power, size/weight
• Limited resources:
• Slower CPU, less memory storage
• Many sensors:
• Cameras, GPS, accelerometers, . . .
• Security and privacy?
11
Other operating systems
• Embedded OS
• Limited CPU, memory, battery
• E.g., Home devices, environmental sensors, IoT • Special-purpose functionality
• Security problem is a disaster
• Real-time OS
• Time-based guarantees
• E.g., airplanes, cars, production machinery
12
OS Overview
General structure
+—————————+
| App. | Libs | Utils |
+—————————+
System calls
+—————————+ —-
| OS Kernel |
| ———————– | OS
| Drivers |
+—————————+ —-
| Hardware |
+—————————+
• Hardware-OS interactions • OS-Application interactions
13
Kernel
• The Core of the Operating System
• Complete control over everything in the system • Provides the main functionalities and services:
• Process and Thread Management • Memory Management
• File System and I/O
• Inter-Process Communication
14
Hardware-OS interactions
• Drivers in the OS interact with hardware
• Corresponding hardware drivers use the following interfaces for I/O
• Memory-mapped I/O (input/output) • Port-mapped I/O
• Direct memory access
• CPU interrupts
• A signal to the processor emitted by hardware
15
OS-Application interactions
• Allow users to interact with the OS
• Allow programs to use common services
• System calls (synchronous)
• Wrappers: Libraries
• Signals (asynchronous)
• Delivered by kernel but can be initiated by applications
• OS interacts with user programs
• Memory
• OS Controls user programs
• User programs can be killed
16
A key question
OS performs critical tasks; how does the OS prevent accesses from malicious applications?
• Such as overwriting kernel data structures or manipulating hardware
17
Answer: Sleeping beauty model + architecture support
• Sleeping beauty model
• Most of the time the OS is sleeping
• OS runs in response to “events”
• Only the OS can manipulate hardware or critical system state
• Architecture support
• Goal: OS must have exclusive access to hardware and critical data structures • Support: Privilege mode
• A status bit in a protected control register indicates the mode
18
CPU modes (rings)
NOTE: Modern OS such as Unix and Windows typically uses only ring 0 and ring 3, and drivers run in ring 0.
19
Kernel mode
• OS runs in kernel mode: enforced by the status bits (how many bits?) in CPU
• Higher privileges than user mode • Access to hardware resources
• Access to protected memory
• Access to OS data structures
20
User mode
• Applications, utilities, shell run in user mode • Restricted access to
• System resources
• Kernel data structures
21
A key question
Applications are “isolated”, so how do applications get access to desired resources (CPU, memory, disk, etc.)?
Example: open and read a file in disk
22
Answer: System calls
• Kernel API: well-defined, small set of operations • Entry points into the kernel
• Provide restricted access to the kernel
• Operations upon system calls
• User program executes a TRAP instruction • 32-bit: int; 64-bit: syscall
• Switches to kernel mode
• Passes parameters, system call number (like ID) • Kernel looks up system call table
• System call handler is invoked
• Results returned to user program
23
System call example: open, read, close
int fd, sz;
char *c = (char *) calloc(100, sizeof(char)); fd = open(“foo.txt”, O_RDONLY);
if (fd >= 0) {
sz = read(fd, c, 10);
close(fd); }
Q: what are done in the OS?
24
System call implementation
• System calls are specified using syscall numbers
• open: 2; read: 0; close: 3
• Linux right now has more than 300 system calls • Issued through a TRAP instruction
• 32-bit: int; 64-bit: syscall
25
Assembly for making a syscall—write
_start:
movq $1, %rax ; use the write syscall
movq $1, %rdi ; write to stdout
movq $msg, %rsi ; use string “Hello World”
movq $12, %rdx ; write 12 characters
syscall ; make syscall
• Problem: Assembly is not easy to write
26
Libraries
• Pre-written and pre-tested functions
• Programmers can call library functions in their programs • Two types:
• Wrappers for system calls • fread(), fopen(), etc.
• User-level utility library functions
• Examples:
• libc, libc++
27
User-level utility libraries
• Implement commonly-used functions
• Programmers don’t have to reinvent the wheel
• Think about how would you implement string copy • Examples:
• Random number generation (rand, srand, . . . ) • String operations (strcpy, strcmp, strlen, . . . )
28
Advantages of libraries?
29
Advantages of libraries?
• Reduce load on programmers • Standard functions
• Hide complexity
• Less errors
• Well designed and tested
• Efficient implementation
• Available for high-level languages
29
Unix Overview
What is Unix?
• Unix is a family of multitasking, multiuser computer operating systems • Highly popular
• Many variants exist
• Derivatives: Linux, iOS/MacOS, Android, Debian, Ubuntu, *BSD, etc. • Design principles:
• Multiprogramming • Flexibility
• Extensibility
30
Unix history
• Origin: MULTICS (1965): a time-sharing operating system Computing Service • UNIX (1969): Developed at Bell Labs
• By and • Developed in C
• Architecture-independent
• Several Evolution Paths:
• AT&T System V (1983) -> SCO Unix
• BSD (1980) -> FreeBSD, NetBSD
• Linux (1991-) -> Android
• Other variants: Solaris, HP/UX, IBM AIX, S/X
31
Common features
• Similar tools and user interfaces • Similar APIs
• POSIX Standards
32
Variations
• Shells, tools, and user interfaces • APIs
• Underlying implementation
33
Unix system structure
34
The Linux case
35
Shell
• A command-line interpreter • Basic interface to the OS
• Allows users to interact with the OS
• Command interpreter
• Parses and executes several commands
• Many Unix Shells
• bash
• zsh
• Bourne sh • csh, tcsh, • ksh,
36
Shell as command interpreter
• “Read-eval-print” model
• Read user input
• Evaluate the input and execute command(s) • Print output
• Example: ls –l
• User types above command
• Shell reads and parses the input
• Shell invokes “ls” command (a user program in /bin/ls) with argument “-l” • Shell prints the output produced by the command
37
Shell as a program
• Shell itself is just another user-level program
• Examples: /bin/bash, /bin/sh
• No special privileges
• Primary Objective: Run other useful programs
• Shell interacts with the OS using the API and through other programs
38
Shell commands
• Built-in commands
• Implemented within the shell itself
• E.g., echo, ls, cat
• External commands
• Other programs executed by the shell
• Path needs to specified (or be in the environment) • File should be executable
• E.g., “app” is the file located as “/path/app”
39
Environment variables
• Environment: A set of variables associated with the shell • Useful for the shell to remember common settings
• Examples:
• PATH: Set of directories to look for commands
• That is why we don’t have to type “/bin/ls” but just “ls”
• HOME: Home directory of the user
• Try: echo $PATH and printenv
40
Standard I/O
• Standard input (stdin): source of input data for a command or program • Default: Keyboard
• File descriptor 0
• Standard output (stdout): destination of output from a command or program
• Default: Display
• File descriptor 1
• Standard error (stderr): destination of error messages • Default: Display
• File descriptor 2
41
Shell redirection
• Redirect the input or output of a command to a file
• Input redirection (<): Takes input from a file instead of keyboard • sort < file
• Output redirection (>): Send output to a file instead of display • ls-l>file
• What about: cat file1 >> file and cat file 1>&2
42
Shell pipes
• Pipes: prog1 | prog
• Allow multiple commands to be linked together • Connects output of prog1 to input of prog
• Examples:
• ls-l|more
• cat foo | sort | head
• How will you do the above using only redirection?
• Most UNIX commands consume and produce plain text data
43
Unix file system
• Tree-based hierarchy
• File system has a root (/)
• Each user has a home directory ($HOME) • There are several standard directories
• E.g.: /bin (binary files), /dev: device files, /lib: libraries, . . .
44
Unix directory hierarchy
45
Wrap-up
• OS evolution
• How does the OS prevent accesses from malicious applications?
• How do applications get access to desired resources (CPU, memory, disk,
etc.)?
• Syscall and libraries
• Unix structure
• Shell
• Unix file system
46
Next lecture
• Programs
• Reading: . 2
• Reminder: Team list due on 09/16
47