复习：操作系统的两个视角

应用视角 (自顶向下)

• 操作系统 = 对象 + API
  • 应用通过 syscall 访问操作系统

机器视角 (自底向上)

• 操作系统 = C 程序
  • 运行在计算机硬件上的一个普通程序

为操作系统建模

操作系统 = 状态机的管理者

• 当然，它自己也是状态机，有自己的状态

有了一个有趣的想法……

• 能不能我们自己定义 “状态机”
  • 用我们喜欢的语言、喜欢的方式
  • 不要受限于 C、汇编……
• 自己模拟状态机的执行
  • 不就有了一个 “玩具操作系统” 吗？

为操作系统建模 (cont'd)

简化的操作系统模型

• 用更方便的编程语言描述状态机
  • 依然是程序
  • 依旧是 “数学严格” 的对象
• 但用更简单的方法实现操作系统
  • 管理状态机
  • 执行系统调用

表示状态机：当然是程序

Life is short, you need Python!

def StateMachine():
    b = sys_read()

    if b == 0:
        sys_write('I got a zero.')
    else:
        sys_write('I got a one.')

def main():
    sys_spawn(StateMachine)

玩具操作系统

操作系统中的对象

• 状态机 (进程)
  • Python 代码
  • 初始时，仅有一个状态机 (main)
  • 允许执行计算或 read, write, spawn 系统调用
• 一个进程间共享的 buffer (“设备”)

系统调用

• read(): 返回随机的 0 或 1
• write(s): 向 buffer 输出字符串 s
• spawn(f): 创建一个可运行的状态机 f

如何实现？

难点是多状态机的管理

• 如何在状态机之前来回切换
• 实现我们单 CPU 上运行多个程序的效果？

一些途径

• SimpleC 模拟器支持 “单步” 功能
  • 创建多个模拟器对象单步执行 (J2ME KVM 就是如此)
  • 或者干脆偷懒，启动多个 pdb
• 是否有语言机制能 “暂存” 函数的运行状态，并且之后回复？
  • 有：Generators/Coroutines

于是，我们有了 “操作系统”！

30 行代码讲完《操作系统》

• 进程
• 系统调用
• 上下文切换
• 调度

你会在 Linux Kernel 中看到 “类似” 的代码

• “procs” → cpu->runqueue
• “current” → current = (current_thread_info()->task)

玩具的意义

玩具实现了最重要的机制

• 状态机管理、系统调用、上下文切换
• 许多更复杂的机制只是 “更多的代码”

我们甚至没有脱离真实的操作系统

void sys_write(const char *s) { printf("%s", s); }
int sys_read() { return rand() % 2; }
void sys_spawn(void *(*fn)(void *), void *args) {
    pthread_create(&procs[n++], NULL, fn, args);
}

• 学习路线：先理解玩具
• 再理解真实系统和玩具的差异

并且，打开潘多拉的盒子……

因为 spawn 的存在，操作系统中有多个状态机 (进程)

def Process(name):
    for _ in range(5):
        sys_write(name)

def main():
    sys_spawn(Process, 'A')
    sys_spawn(Process, 'B')

• 操作系统会 “雨露均沾” 地运行它们
• 但 buffer 是所有状态机共享的
  • 于是有了并发……
  • 操作系统是最早的实用并发程序