[现代操作系统] 操作系统引论

操作系统引论

• 操作系统引论
  
  • 0.1. 位置
  • 0.2. 功能
    
    • 0.2.1. 向应用程序提供抽象–自顶向下
    • 0.2.2. 资源管理–自底向上
  • 0.3. 发展历史
    
    • 0.3.1. 第一代 (1945~1955)–真空管和穿孔卡片
    • 0.3.2. 第二代 (1955~1965)–晶体管和批处理系统
    • 0.3.3. 第三代 (1965~1980)–集成电路芯片和多道程序设计
    • 0.3.4. 第四代 (1980~)–个人计算机
  • 0.4. 操作系统结构
    
    • 0.4.1. 单体结构
    • 0.4.2. 层次式系统
    • 0.4.3. 微内核
    • 0.4.4. Client-Server 模式
    • 0.4.5. 虚拟机
      
      • 0.4.5.1. 优点
      • 0.4.5.2. 条件
      • 0.4.5.3. Ⅰ 型管理程序
      • 0.4.5.4. Ⅱ 型管理程序
      • 0.4.5.5. 准虚拟化 (paravirtualized)

0.1. 位置

0.2. 功能

0.2.1. 向应用程序提供抽象–自顶向下

抽象是管理复杂性的一个关键, 好的抽象可以把一个几乎不可能管理的任务划分为两个可管理的部分:
* 有关抽象的定义和实现
* 用这些抽象解决问题

0.2.2. 资源管理–自底向上

在相互竞争的程序之间有序地控制对处理器, 存储器以及其他 I/O 接口设备的分配

0.3. 发展历史

0.3.1. 第一代 (1945~1955)–真空管和穿孔卡片

ENIAC , 程序设计是用纯粹的机器语言,

使用: 程序员在墙上的机时表上预约一段时间,, 然后到机房中将他的插件板接到计算机中, 在接下来的几小时等待 (计算的都是简单的数字运算, 如制作对数表)

0.3.2. 第二代 (1955~1965)–晶体管和批处理系统

批处理系统 (batch system), 在输入室中手机全部的作业 , 然后用一台相对便宜的计算机, 读到磁带上. 磁带被送到机房里并装到磁带机上. 然后操作员装入一个特殊的程序 (现代操作系统的前身), 它从磁带上读入第一个作业并运行. 如此反复

0.3.3. 第三代 (1965~1980)–集成电路芯片和多道程序设计

多道程序设计 (multiprogramming): 若当前作业因等待磁带或其他 I/O 操作而暂停时, 为了不让 CPU 一直等待这一个作业, 将内存分几个部分, 每一部分存放不同的作业, 在一个作业等待 I/O 时, 可以让另一个作业使用 CPU.

在内存中防止多个作业需要特殊的硬件来保护, 以免作业的信息被窃取或受到攻击.

程序员希望得到更快响应, 由此出现分时系统(timesharing).

0.3.4. 第四代 (1980~)–个人计算机

大规模集成电路 (LSI) 的发展, 晶体管个数在单位平方厘米面积的芯片上可达数千个.

逐步发展处 网络操作系统, 分布式操作系统

0.4. 操作系统结构

0.4.1. 单体结构

• 主程序: 处理服务过程请求
• 服务过程: 执行系统调用
• 实用过程: 辅助服务过程

0.4.2. 层次式系统

0.4.3. 微内核

传统上, 所有的层都在内核中, 但是这样并没有必要. 尽可能减少内核态中功能的做法更好. 要知道, 代码量越大, bug 越多.

思想
为了实现高可靠性, 将操作系统划分成更小的, 良好定义的模块. 只有其中一个模块–微内核 运行在内核态上.

0.4.4. Client-Server 模式

将进程划分为两类,
* 服务器: 提供服务
* 客户端: 使用服务
通常在系统最底层是微内核

0.4.5. 虚拟机

0.4.5.1. 优点

• 节省硬件成本, 如不同服务器 (web, ftp, mail…) 可以在一台宿主机上
• 同时运行多个 OS 的需求 (如软件开发过程, 运行在某些 OS 不支持的程序)
• 检查点, 虚拟机的迁移: 仅需移动内存映像

0.4.5.2. 条件

• 敏感指令( sensitive instruction ).: 有内核态和用户态的 CPU 的一组只能在内核态执行的指令集, 比如 I/O 指令, 改变 MMU 状态的指令等,
• 特权指令( privileged insttruction): 在用户态下执行会引起陷入

当 敏感指令是 特权指令的子集时, 机器才是可虚拟化的

解决的基本思想: 创建容器使得虚拟机在其内运行

0.4.5.3. Ⅰ 型管理程序

在其上的 OS 称为客户操作系统

虚拟机在用户态以用户进程的身份运行, 因此不允许执行敏感指令, 否则崩溃

在支持 VT 技术的 CPU 上, 客户操作系统执行敏感指令会发生陷入. 管理程序分析指令
* 来自客户操作系统: 管理程序调度将要执行的指令
* 来自虚拟机中用户程序: 仿真面对运行在用户态的敏感指令时真是硬件的行为

0.4.5.4. Ⅱ 型管理程序

在其上的 OS 称为宿主操作系统, 如上图 b

VMware 就是采用的这种管理程序:
当运行一个二进制文件, VMware 先浏览代码段以寻找基本块(basic block).

所谓基本块就是以 jump, call, trap 等改变控制流的指令结束的可顺序执行的指令序列, 而基本块中就不含其他改变 程序计数器 的指令

如果基本块中含有敏感指令, VMware 将其替换为相应的 VMware 过程调用, 基本块的最后一条指令也被过程对用替换

这种 找出, 仿真敏感指令 的技术成为 二进制翻译(binary translation)

所以, 即使在不可虚拟化的硬件上, Ⅱ 型 也能正常: 因为所有的敏感指令被仿真, 不会被真正的硬件执行, 管理程序的调用可以代替.

0.4.5.5. 准虚拟化 (paravirtualized)

前面介绍的两种, 在其上的客户操作系统都是没有修改过的. 可以更改客户操作系统的源码, 将其中的敏感指令都转换为 管理程序调用. 这就要给管理 程序 定义 过程调用集合, 从而形成 API, 虽然这个接口是供客户 OS, 而不是 应用程序.

其实就将管理程序变成了一个微内核.

这种方法就是准虚拟化, 这样会使得虚拟机技术更容易被支持和使用

问题:
* 如果所有敏感指令都被代替, 操作系统不能在物理机器上运行
* 如果市场下有很多管理程序, 有不同的 API 接口

Amsden 的一个解决方案:
当内核需要执行一些敏感指令操作时会调用特殊的例程 (称为 VMI 虚拟机接口), VMI 形成的底层与硬件或管理程序进行交互. 将 VMI 设计得通用化, 不依赖硬件或特定的管理程序