程序设计需要考虑的基本元素

1. 基本的表达形式: 基本的数据表达与基本的过程表达
2. 组合的方法: 将基本表达组合起来构成复合的元素, 如 Lisp 的组合式
3. 抽象的方法: 为复合对象命名, 从一个新的抽象层次操作非基本单元

在 lisp (SICP 使用 scheme 方言) 中有如下体现:

上述概念在 Lisp 的体现

表达式:

操作系统的 libc 支持

之前 我们说到系统从其功能实现上的目的是: 管理各种硬件资源,实现隔离并发与虚拟化. 但是站在一般用户的角度来说, 一个操作系统要有良好的生态, 支持应用程序才能被广泛使用. 而应用程序是由编程语言开发的, 这就要求操作系统能够支持一些语言(特别对于C语言)的标准库.

“C库”, “C标准库”, “C运行时”, gibc/musl/mscrt:

• C 标准库指实现了 ISO C 标准 (C11/C17) 的函数库, 提供我们耳熟能详的 C 标准 API, 常见的实现有 glibc 或 Microsoft CRT, 不常见的其他实现还有 musl 和 BSD libc 等. (musl 因为其标准兼容性被很多人青睐, BSD libc确实见的就比较少了)
• C 运行时一般指 C 程序启动(和终止)所需的底层代码 (crt0.o 或 crt1.o), 也有(我个人认为)有些混淆视听的说法将其等同于 C 标准库. Windows 中 msvcrt.dll 将其明确区分于标准库, Linux 通常不提及 C 运行时(glibc/musl 并未将其拆分)
• C 库通常指任何 C 标准库或 “当前系统上的 C 标准库”, 例如 “gentoo 的 C 库是 musl” 是说 gentoo 发行版的默认 C 标准库库是 musl.

标准库和内核之间的接口通常是系统调用, 因此这里分析支持 libc 主要是分析其需要的系统调用, 以及 Starry Next 及 ArceOS 对这些系统调用的具体实现.

组件化操作系统设计与实现

oscamp 第三节阶段总结. 由于部分操作系统原理性质的内容在二阶段中已经学过了, 因此总结主要针对两部分:

1. 新概念: ArceOS 在传统内核上的创新
2. 老概念: 与 rCore 的实现不同的部分, 以及分析原因

为什么要组件化?

ArceOS 的优势区间在于快速针对特定领域构建出一个最合适的内核, 主要解决的痛点就是”从头开发一个操作系统太繁琐”, 而”现成的方案并不完全适用于应用场景”. 一些操作系统的可扩展性通过内核编译选项或者配置文件来实现, 但是这种方法无法在更深层次修改组装一个操作系统内核, 因此 ArceOS 采用了组件化的方案灵活组装某些功能.

操作系统设计与实现中常用的 Rust 特性

oscamp 第一阶段的 rustlings 总结, 但因为去年写过一次 rustlings 了, 题目比较基础(除了最后的算法和数据结构实现有点麻烦)之前也接触过不少 Rust, 所以这次是总结一下二三阶段中特别需要的 Rust 特性

结构体和枚举

注意元组结构体

1
2
3
4
5

struct TupleStruct(u32, u32, u32);
let tuple_obj = TupleStruct {0, 255, 0};
assert!(tuple_obj.0, 0);

struct UnitStruct;

从 SBI 开发出一个操作系统内核

以 rCore 为例, 介绍一个操作系统从 RustSBI 开始, 从批处理系统到分时多任务系统, 包括地址空间/进程/文件系统的实现, 最后实现多线程以及同步互斥的各种机制.

暂时集中在一篇文章里, 以后有需要再分章节记录

运行环境配置

用 Rust 开发操作系统内核源代码, 通过 rustc 交叉编译到 riscv64gc-unknown-none-elf (一般情况下是 x86_64-unknown-linux-gnu), 通过 rust-objcopy 提取出 bin, 然后放到 qemu-system-riscv64 模拟器进行模拟, 大概是这么个工具链.

CSAPP3e第四章[草稿, 这一篇还在写]

这一章理解难度不大, 但是内容很多, 比较复杂, 你可能读着读着时而觉得”我去这简直是艺术品”时而觉得”我他妈快睡着了”。

指令集体系结构

• 指令集与指令编码
  pushq/popq二义性(数据操作在外侧, 栈指针变化在内测)
• 编码寄存器
• 异常处理

描述体系结构的方法: 硬件设计语言 HCL