# Operating System Ch 2 - OS Structure

[清大周志遠老師的課程錄影](https://www.youtube.com/playlist?list=PLS0SUwlYe8cxj8FCPRoPHAehIiN9Vo6VZ)的筆記。

contributed by <[`kaeteyaruyo`](https://github.com/kaeteyaruyo)>

## 作業系統提供的服務

* 作業系統提供的服務包山包海
* 使用者介面（殼層）
* 執行程式
* 操作 I/O 裝置
* 操作檔案系統
* 通訊
* 錯誤偵測
* 資源分配（如記憶體管理）
* 簿記 ==（這個不太懂）==
* 硬體保護 (Protection) 和資訊安全保護 (Security)
* 作業系統的核心 (kernel) 外層還有一個**殼層 (shell)** 用來提供使用者（的應用程式）對作業系統下指令
* **CLI Shell**: 命令列介面，Unix 系統上常見有 C shell (csh), Bourne shell 及其衍生 (sh, bash, zsh)
* **GUI Shell**: 圖形化介面，Unix 系統上常見有 gnome, KDE 等
* 一台電腦上的程式之間要互相溝通時需要做資料傳遞，有兩種模式（後面會更詳細介紹）
* **Message passing**: A 程式把資料從自己的記憶體複製到 OS 的記憶體，再讓 B 程式從 OS 的記憶體把資料搬回自己的記憶體
* **Shared memory**: 透過 OS 事先建立好的共享記憶體，讓 A、B 兩個程式都能自己去讀寫

## 作業系統提供給應用程式的介面 (API)

* System call 和 OS 的 API 是不一樣的東西
* System call 是 OS 程式碼的一部份，**通常由組合語言寫成**，速度非常快，可以直接操作電腦硬體，必須**要透過軟體中斷**來執行
* API 則是 OS 為了讓開發者可以**方便使用 system call 而包成的函式介面**，例如 C library 就是以 C 語言寫成的 API，裡面的 `printf()` 函式可以去呼叫和寫入標準輸出有關的 system call
* 當我們呼叫 API 的時候不一定真的會去呼叫到 system call，因為 API 只是方便應用程式開發者去使用的功能，當這個功能跟底層硬體沒關係時就不會用到 system call
* 也有可能兩個不同的 API 底下其實是同一個 system call。例如：`malloc()` 和 `free()` 底層在做的事情都只是在改變一個程式可用的記憶體範圍的 limit address 的值而已，所以他們都是呼叫 `brk()` 這個 system call
* 三種最常見的 API
* Win32 API for Windows
* POSIX API for POSIX-based systems (Unix, Linux, MacOS)
* Java API for the Java virtual machine (JVM)
* 為什麼不讓應用程式直接呼叫 system call 就好了還需要 API？
* **方便性**：system call 每一個能做到的事情很少，要做一個完整個行為可能需要很多個 system call，全部包起來抽象化成一個函式比較方便
* **可移植性**：同樣都是開檔寫檔等動作，不同作業系統的 system call 可能名字長相等不一樣，為了讓開發者不用換一個 OS 就要重寫一次程式碼，多一層 API 會讓程式碼比較有可移植性
* **效率性**：不是所有的行為都需要用到跟 kernel 有關的服務，如果是應用層可以自己做到的事，就不用勞煩 OS

## 作業系統架構

* 作業系統的架構演進
* 簡單架構 (Simple architecture)
* 分層式架構 (Layered architecture)
* 微核心架構 (Microkernel architecture)
* **模組式架構 (Modular architecture)** <- 現今最常見的架構
* 虛擬機 (Virtual Machine)
* 簡單架構
* ~~就是沒有架構~~最早期的架構，大概分成軟體 -> OS -> 硬體這樣三層，在 OS 這一層所有東西混在一起，沒有任何架構可言。例如：MS-DOS、早期的 Unix
* 優點是很簡單，缺點是很不安全（沒有權限的概念），很難擴展跟維護
* 分層架構
* 像網路那樣分層，愈上面愈靠近使用者，愈下面愈靠近硬體
* 上層依賴於下層的 API，但下面沒辦法往上 call
* 優點是好管理，缺點是分層困難（I/O 層依賴於記憶體層，但記憶體層也依賴於 I/O 層），而且分層呼叫函式會降低效率
* 微核心架構
* 把 OS 提供的服務都**劃分到接近使用者層**的地方，真正 OS 的部份只做最少的事情，例如去協調這些服務之間的合作
* 在這種架構下服務之間是透過 message passing 來溝通的
* 優點是模組化、很容易擴充，缺點是變得又更慢了
* 近期有一些**嵌入式系統**的 OS 會採用這種架構
* 模組式架構
* 保留微核心模組化/物件導向的概念，但是把這些模組**都抓進核心層提升他們的權限**，各個模組之間可以直接透過 interface 互動
* Kernel module 可以很容易的擴充到 OS 上
* 是現代最常見的架構

### 虛擬機 (Virtual Machine)

* 虛擬機這個技術 4、50 年前就有了（！）
* 一開始虛擬機的構想是說：為什麼我們要用 OS 來保護不同使用者的程式之間不要互相被干擾，我們就直接在同一個電腦硬體上面給每一個使用者一個自己的 OS 不就好了ㄇ？於是虛擬機的概念就誕生了
* 但是因為以前的電腦計算效能不夠好，光是跑很多使用者的程式就已經累死了根本沒辦法再每個人都跑一個 OS。直到近年來硬體效能大幅增加虛擬機才變得可行
* 一台電腦上可以有多個虛擬機同時運作，他們執行在 host machine 的作業系統之上，每一個虛擬機都有一個自己的 kernel
* 這些虛擬機的 kernel 應該要以為自己直接跑在硬體上，所以自己是 kernel 層，但實際上他們是在實體機器的 user 層，這會造成一個問題：他們沒辦法執行 system call
* 當他們需要執行 system call 的時候，他們會先造成一個 software interrupt，讓底下的實體 OS 知道有人需要使用硬體，再由實體 OS 真的去執行他們要用的那個 system call，這樣會造成效能很慢
* 近年來有些機器主打「**硬體支援虛擬化 (hardware support)**」，意思就是說他們硬體上除了原本的 status bit 除了有 kernel mode/user mode 之外，現在還多了一個 VM mode，如此一來這些機器上的 VM 的 kernel 就可以直接呼叫 system call，不用再讓實體的 OS 代勞了
* 除了 system call 之外，另一個頭痛的問題是有些指令在 user mode 和在 kernel mode 下執行會有不一樣的結果，這些指令叫作 **critical instruction**。要讓虛擬機可以正確執行這些指令就需要做額外的處理，這是虛擬機最大的挑戰
* 虛擬機的應用
* 提供系統資源完整的防護（不會被其他使用者影響）
* 解決系統相容性的問題（業界常常會有需要跑在 legacy system 上的程式，有VM就不用為了單一個程式又買一台電腦裝一個特定的OS）
* 加速OS的軟體的研究與開發（在寫OS的程式時可以直接跑在VM上，不用跑在實體機器上壞掉了電腦還要重開）
* 在雲端計算的環境下，可以做資源的有效利用
* （省略了 Full Virtualization 和 Para-virtualization 的比較）
* Java Virtual Machine
* Java 這個語言是以虛擬機的邏輯在運作的，但這個虛擬機要做的事情只有翻譯 instruction，不管那些系統管理或硬體操作等事情

----

[<< Ch 1 - Introduction](https://hackmd.io/@kaeteyaruyo/operating-system-1) | [目錄](https://hackmd.io/@kaeteyaruyo/operating-system-index) | [Ch 3 - Processes Concept >>](https://hackmd.io/@kaeteyaruyo/operating-system-3)