本文提出了一种用户态缺页异常处理框架，可以轻松适配不同的处理策略，适用于高并发环境。其亮点在于：
- 框架的易用性：
- 基于 Linux 的 Semi-Microkernel 设计
- 透明
- 性能：
- 采用了微内核和外核思想中的 upcall 设计
- 采用了先进的异步批处理 IO 后端 io_ring
从软件层去看，目前内存密集型应用越来越多，如 TB 级的机器学习、大型图计算，内存数据库等。从硬件层去看，硬件新特性有很多，比如分离式内存、分层内存等。这些新的变化都对内存管理策略提出了新的挑战。
通用操作系统的内存管理策略并不适用于内存密集型应用，也不能针对性的利用硬件新特性。有研究表明最大的系统瓶颈是内存管理而不是设备带宽。
设计模式是一个工程问题，它不能为某个问题提供具体的答案，它只能让答案写得好看一些。
更进一步地说，设计模式是用于解决代码复杂度高（不是算法复杂度）的问题，这会引发难以阅读，难以维护等伴生问题。当代码量小，复杂度低，没有什么维护需求的时候（比如说科研代码），其实是没有必要采用规范的设计模式的。
我个人学习设计模式，并不是为了写代码（因为我写的代码就是科研代码），而是为了更好的阅读代码，因为大型工程代码都会或多或少遵循设计模式的思路。
很多设计模式解决的复杂度问题，是客观存在的，认识这些问题有助于设计出更加简洁健壮的架构；但是有些问题可能只是类似 Java 等语言表述能力不够所导致的，不用太较真。
VeriSMo 的可信基只包括硬件和它自己（VM），剔除了对于 Hypervisor 的信任。传统的 VM 的安全服务是由 Hypervisor 负责的，如果认为 Hypervisor 是不可信的，那么就不能由它来提供安全服务。AMD 提供了新的安全架构 SEV-SNP，它为在 VM 中独立实现安全服务提供了支持，VeriSMO 就利用了这个硬件特性。
除了利用新的硬件安全特性外，VeriSMo 在开发时完成了形式化验证来确保安全性。VeriSMo 的开发语言是 Rust，已经确保了部分的内存安全性（也就是 Rust Checker 承担了部分形式化验证的任务），距离完全的形式化验证还有两个挑战：
为了解决挑战 1，VeriSMo 将验证拆分成了 2 层，上层为机器模型层（Machine Model），用 model verify 专门约束 Hypervisor 的行为，下层为实现层（Implement），用于解决排除了 Hypervisor 干扰后的 VeriSMo 本身的验证问题。
这篇文章是对于旋元佑语法俱乐部的一个注释总结。行文思路基本上和这本电子书的章节保持一致。
语法是对于语言的规律总结，这类似于物理是对于客观世界的规律总结。不过应当注意到，即使掌握了语法，也并不能短时间内提高英语水平，因为在语法的指导下使用语言，同样是一个需要习惯和精进的过程。这就像掌握了物理定律和物理满分之间依然存在很大差距一样。
旋老师的语法和我中学学过的语法并不一样，旋老师倾向于建立一种“大一统”的理论来解释所有的语言现象，而中学语法则更加繁杂和缺少一致性。在加上我这次学习语法已经是大四，在逻辑思维上相比于中学已经有了很大的进步。所以总的来说，语法更加“讲理”了。
但是旋氏语法的缺点我个人感觉有两个，一个是因为过于“统一”，导致需要引入一堆与中学语法似是而非的概念，这些概念类似于物理学上的“波粒二象性”一样，对中学语法是一种挑战；并且因为旋老师是台湾人的缘故，所以在表达习惯和方式上也与大陆存在一定的差异（也就是他写的中文有点难看懂）。另一个是旋老师在建立了“统一”的理论后，并没有充分利用这些规律推导出中学语法甚至是其他中学语法难以推导的其他语言现象。