OS Note Chapter 2: Operating System Structures

Operating System Services

Operating systems provide an environment that offer services to programs and users

Functions to the user

• User interface (UI)
  • Command-Line Interface (CLI), Graphics User Interface (GUI), touch-screen, batch processing (批处理)
• Program execution
  • Load a program into memory
  • Run a program, and then end execution.
• I/O operations
• File-system manipulation
  • Read-write
• Communications
  • Process exchange information
• Error detection
  • Handle possible errors (from hardware or software)

Functions for the efficient operations

• Resource allocation

  • When multiple users or multiple jobs are using computer concurrently, resources must be allocated to each of them
    • Many types of resources
      • CPU, main memory, file storage, I/O devices.

• Logging (日志)

  • To keep track of which users use how much and what kinds of computer resources

• Protection and security

  • Protection
    • Ensure that all access to system resources is controlled
      • The owners of information stored in shared computer system may want to control the use of that information
      • Concurrent processes should not interfere with each other
  • Security
    • Avoid attack from outside the system

A View of Operating System Services

System Programs

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

• File manipulation

• Status information sometimes stored in a file

• Programming language support

• Program loading and execution

• Communications

• Background services (e.g., launch OS, disk checking, daemons(守护进程))

• Application programs

Most users’ view of the operation system is defined by system programs, not the actual system calls (for system or application programmers)

Why Applications are Operating System Specific

• Apps compiled on one system usually are not executable on other operating systems
  • Each operating system provides its own unique system calls
• How can apps be used in multi-operating systems
  • Written in an interpreted language like Python, Ruby, and interpreter available on multiple operating systems
  • Written in a language that includes a VM containing the running app (like Java)
  • Written in a standard language (like C), compiled separately on each operating system to run on each OS
• Application Binary Interface (ABI) is architecture level about how different components of binary code can interface for a given operating system on a given architecture in low-level details

Operating System Interface

User Operating System Interface

CLI

CLI (Command Line Interface) or command interpreter allows direct command entry

Commands are sometimes implemented in kernel [commands built-in], sometimes by systems program [names of programs]

Advantage: adding new features doesn’t require modification of interpreter

Shell (vs. Kernel)

• Multiple flavors of interpreters implemented

• Different types of shells in Linux

  • The Bourne Shell (sh)
  • The GNU Bourne-Again Shell (bash)
  • The C Shell (csh)
  • The Korn Shell (ksh)
  • The Z Shell (zsh)

[Kernel] <- Shells

GUI

GUI (Graphical User Interface): User-friendly desktop metaphor (象征) interface, icons represent files, programs, actions, etc.

Invented at Xerox PARC (1970s)

Touchscreen Interfaces

Touchscreen devices require new interfaces

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

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

System Calls, API,C Libraries

System Calls

System calls provide an interface to the services made available by an operating system

• Examples: write(…), read(…) on Unix/Linux
• Typically written in a high-level language (C or C++)
• An example: system call sequence to copy the contents of one file to another file

Types of System Calls

• Process control
• File management
• Device management
• Information maintenance
• Communications
• Protection

Examples of Windows and Unix System Calls

API

Typically, application developers design programs according to an API rather than directly system calls.

• The API (Application Programming Interface) specifies a set of functions that are available to an application programmer.

• e.g. When call Windows function CreateProcess, actually, it is making a system call NTCreateProcess to Kernel

Three most common APIs (libraries)

• Win32 API for Windows

• POSIX API for POSIX-based systems (including virtually all versions of UNIX, Linux, and Mac OS X)

  • POSIX (Portable (可移植的) Operating System Interface) is a family of standards specified by the IEEE Computer Society for maintaining compatibility between operating systems.

• Java API for the Java virtual machine (JVM)

API and System Call

The caller just needs to obey API

• know nothing about how the system call is implemented
• Most details of OS interface hidden from programmer by API

C Standard Library vs System Call

C standard library

• contains functions which make system calls or do not make system calls

• makes programmers’ work much easier

Advantages of using C Standard Library

• It is simpler to call a function in a C standard library rather than to make a system call

• Portability

  • Source code executed in one OS can be run in another OS

  • e.g., printf

    • All OSes supports printf

    • Source code that use printf can be reused in another OS after re-compiled.

    • The code of printf itself is different on different operating systems.

    • If direct system call is used, program is not portable.

Advantages of using system calls

• System calls are usually more powerful than functions from the C Standard Library

  • e.g., you can create processes, share memory between processes, etc. These advanced features are not available in the C Standard Library.

• It’s a little bit faster than using a library function (since internally the library function uses a system call anyway).

In practice, for normal programmers, code portability is the most important issue, so use functions from the C Standard Library as much as possible in your own code!

Standard C Library vs C POSIX Library

The C POSIX library

• was developed at the same time as the ANSI C standard.

• includes additional functions to those introduced in standard C

Standard C library vs C POSIX library subset ⊏ superset

Operating System Implementation

Much variation

• Early OSes in assembly language

• Then system programming languages like Algol, PL/1

• Now high level language C, C++

  • High-level language is easier to port to other hardware
  • But slower

• Actually usually a mix of languages

  • Lowest levels in assembly language
  • Main body in C
  • Systems programs in C, C++, scripting languages like PERL, Python, shell scripts

• Emulation can allow an OS to run on non-native hardware

Operating System Structure

General-purpose OS is a very large program

• Linux (2015): 20.2 MLOC (million lines of code)
• Windows 7: 40 MLOC
• Windows 8: 60 (?) MLOC
• Mac OS X (2005): 85 MLOC
• Windows 10: ?

Various ways to structure ones

• Simple structure – MS-DOS
• More complex – UNIX
• Layered
• Microkernel -Mach

Monolithic（庞大而单一） - Traditional UNIX

• The original UNIX operating system: limited structuring (due to early hardware).
• The UNIX OS consists of two separable parts
  • Systems programs
  • The kernel
    • Consists of everything below the system-call interface and above the physical hardware
    • Provides the file system, CPU scheduling, memory management, and other operating-system functions;
    • Consists of a large number of functions in one level

Monolithic Plus Modular - Linux System Structure

• Advantages for monolithic design
  • High speed
  • High efficiency
• Advantages for modular design
  • changes in one component affect only that component, and no others Modules can be modified easily.

Layered Approach

The operating system is divided into a number of layers (levels)

• The bottom layer (layer 0), is the hardware.
• The highest (layer N) is the user interface.
• Each layer is built on top of lower layers with modularity, each layer uses functions (operations) and services of only lower-level layers

Advantage

• Simplicity of construction and debugging.

Disadvantages:

• Hard to define each layer.
• Poor performance.

Microkernels (微内核)

• Moves as much components from the kernel into user space

  • E.g., Mach
  • Mac OS X kernel (Darwin) partly based on Mach

• Communication takes place between user modules using message passing

  • Microkernels provide minimal process and memory management, in addition to a communication facility.
  • Communication between user modules through message passing.

• Benefits

  • Easier to extend to a microkernel and port the operating system to new architectures
  • More reliable (less code is running in kernel mode)
  • More secure

• Detriments/drawbacks

  • overhead of communication between user space and kernel space

Modules

• Many modern operating systems implement loadable kernel modules (best practice) uses object-oriented approach
• Each core component is separate, is loadable as needed within the kernel, talks to the others over known interfaces
• Overall, similar to layers but with more flexible
  • E.g., Linux, Solaris[1], macOS, Windows, etc

Hybrid Systems

• Most modern operating systems: not one pure model (structure)

  • Hybrid combines multiple approaches to address performance, security, usability needs.

• For example

  • Linux and Solaris kernels: monolithic (in kernel memory), plus modular (for dynamic loading of functionality)
  • Windows mostly monolithic, plus microkernel for different subsystem personalities, also provide support for dynamically loadable kernel modules.
  • Apple Mac OS X, Microkernel plus layered, Aqua (GUI) plus Cocoa (API) programming environment

Example:

• macOS: for desktop computers (CPU: Intel)

• iOS： for mobile phone (CPU: ARM)

  • i.e., iPhone, iPad
  • Structured on Mac OS X, added functionality
  • Does not run OS X applications natively

• Darwin

  • Released as open source already
  • Darwin provides two system-call interfaces
    • Mach system calls and BSD system calls
  • Iokit
    • development of device drivers
  • Kexts
    • dynamically loadable modules

• Android

  • Developed by Open Handset Alliance (mostly Google)
  • Developed for Android smartphones and tablet computers
  • Open-sourced (iOS is close-sourced)
  • Similar stack to iOS
    • Based on Linux kernel but modified
  • Provides process, memory, device-driver management
  • Adds power management

• RunTime Environment (RTE) includes core set of libraries and Dalvik virtual machine

  • Libraries include frameworks for web browser (webkit), database (SQLite), multimedia, smaller libc(c library in linux)
  • Dalvik virtual machine
    • Apps are developed in Java plus Android API
    • Java code is compiled to Java bytecode (as usual) then translated to Dalvik bytecode (for historical reasons), later translated to binary ARM microprocessor instructions when you install the app on the mobile phone.
      • .java -> .class -> Dalvik executable (.dex file)-> binary instructions
  • ART VM is replacing Dalvik VM because Dalvik is slow

Building and Booting an Operating System

Operating System Boot

When power is initialized on system, execution starts at a fixed memory location. Operating system must be made available to hardware so hardware can start it.

Step 1:

• Small piece of code – bootstrap loader（引导程序）, BIOS stored in ROM or EEPROM locates the kernel, loads it into memory, and starts it

Step 2:

• ROM code loads boot block (with bootstrap loader) in hard disk
• Bootstrap loader loads kernel

Bootstrap program (引导程序) – simple code to initialize the system

• Load Kernel
• Starts system daemons (守护进程, services provided outside of the kernel)