系统与数据库2014netbsd.org
用 Lua 实现可脚本化的操作系统
Scriptable Operating Systems with Lua
进阶 · 约 60 分钟读完前置知识：操作系统内核基础、Lua 语言基础、C 语言
导读
这篇论文探讨在操作系统内核中嵌入 Lua 解释器，使系统行为可以通过脚本扩展和定制。作者展示了如何让内核功能（如扩展机制）由内核内嵌的解释器执行脚本驱动，从而实现可编程的操作系统。
HN 关注点：把脚本语言嵌入内核这一非常规设计，讨论焦点集中在 Lua 本身的优劣，以及“内核里再塞一个语言运行时”是否明智。
HN 评论精选
这几条评论里：支持 1 质疑 1 补充 1 亲历 1
补充为 Lua 正名：它小巧、易嵌入、API 简洁，常见批评多是误解
给不熟悉 Lua 的人澄清几点常见误解：A. Lua 源码非常小且注释极好；B. 极易集成——把整个源码扔进你的应用就能编译；C. C API 基于栈但设计得比 Python/Ruby 的更简洁，一个下午就能学完；D. 语义上与 JavaScript 非常相似，语法极简，比 Ruby/Python 少很多“魔法”；E. Lua 不只用于游戏脚本，它适合脚本化任何东西；F. “索引从 1 开始”完全是迷思，切换毫无困难。
_vya7查看英文原文
For those who are not familiar with Lua, or who have heard the prevalent "conventional wisdom" about it, here's a quick clarification: A. Lua's source code is really really small and extremely well-commented[1]. B. Lua is super easy to integrate... you can literally just throw Lua's entire source code into your app[2] and it'll compile just fine. C. Lua's C API is super easy to use, and way more thought-out than Python's or Ruby's (no offense to Matz or Guido) -- yes, it is stack-based, but this actually makes its API much simpler and smaller than it would otherwise be. You can probably learn all of it in an afternoon (with the right guide). D. Lua is uncannily similar to JavaScript in semantics, and the syntax[3] is ridiculously simple to learn. Semantically, it has way less magic to learn than either Ruby or Python. E. Lua isn't only for scripting video games. I wish this "conventional wisdom" would just die. Yes, it is good for scripting video games, for the same reason it's excellent for scripting anything. F. Table indices starting at 1 is not hard to reason about, not hard to use, and it's not hard to switch back-and-forth between Lua and languages where indices start at 0. This is a complete myth. [1]: http://www.lua.org/source/5.2/ [2]: like this: https://github.com/sdegutis/mjolnir/tree/master/Mjolnir/lua [3]: here's Lua's EBNF in its entirely, fitting on a single screen for me: http://www.lua.org/manual/5.2/manual.html#9
支持想法由来已久但少有人实现，内置 webserver 很有吸引力，但对嵌入/扩展的区分存疑
很有意思的文章。用脚本扩展 OS 功能的想法由来已久，但实际尝试少得惊人。潜在用途中，OS 内置 webserver 尤其吸引人——许多脚本语言都有 tcp server/client API，嵌入内核不算牵强。若担心性能或安全，某些解释型语言也可编译为原生代码，如可嵌入 C 的 Scheme 实现。有一点没完全理解：“嵌入”与“扩展”的区别到底是什么？总体上，只要对内嵌脚本语言的行为施加合理的安全策略和约束，这个想法既熟悉又合理。
jrapdx3查看英文原文
A very interesting article. While the idea of using scripting to extend OS functionality has been around for a long time, surprisingly few attempts have been made to implement it. Of the potential uses, an OS built-in webserver would be especially appealing. Many scripting languages provide tcp server/client APIs so it doesn't seem too much of a stretch to embed this functionality in a kernel. For example, Tcl's "socket" core command makes it very easy to set up a tcp server or client. If performance or security is an issue, some interpreted languages can also be compiled to native code. There are Scheme implementations that are embeddable in C and can load interpreted or compiled modules. One thing I didn't completely grasp is the distinction of "embedding" vs. "extending". Are these really disjoint ideas? I found this puzzling: "... Extension scripts are loaded into instances of a kernel-embedded Tcl interpreter that execute in independent system processes [22]. A set of extension bindings exposes to the scripts the necessary resources for extending the kernel. What distinguishes our approach from [micro]Choices is our support of scripting by embedding the language interpreter, in addition to scripting by extending it." [emphasis is mine] On the whole, the idea seems familiar and sensible where sane security policies and safety constraints are applied to actions of the embedded scripting language.
质疑质疑：内核嵌入语言运行时增加验证负担，脚本完全可在用户态以受控内存访问实现
这里很多讨论围绕 Lua，而非他们用它做了什么。我认为在内核里再放一门语言和运行时是坏主意——需要验证的代码量大增。我更欣赏 Mill Computing 的安全方案：包括内核在内“人人平等”，这也是许多微内核的思路。即便没有 Mill 的硬件机制，在现代 x86/ARM 上也能以合理性能实现：包路由或 CPU 节流并不需要特权指令，只需对特定内存区域（设备寄存器、缓冲区等）的受控访问，脚本完全可以在用户态完成，开销几乎为零（只是 TLB 翻译成本，反正每次内存访问都要付）。既然选择了脚本语言的灵活性，本来就已放弃不少性能，用户态-内核态切换的成本真的那么重要吗？
c3d查看英文原文
A lot of the discussion here has been around Lua, but not around what they do with it. I think that putting yet another language and runtime in the OS kernel is a bad idea. It makes the amount of code to validate much bigger. I much prefer the Mill Computing approach to security, where "everybody works the same" including the kernel (see http://millcomputing.com/docs/security/ if you have not seen it already). That's also the idea behind many microkernels. Although the Mill CPU embeds basic mechanisms in the hardware to make it easier, I believe this could be achieved on modern x86 or ARM as well with reasonable performance. You don't need privileged instructions to deal with packet routing or CPU throttling, you only need controlled memory access to specific regions of memory (e.g. device registers, buffers, etc). I see no reason why the scripts could not do their work from user-space, with kernel-controlled access to the regions of memory they need to operate. And the overhead in doing that is practically zero (basically, it's the cost of the TLB translations, which is paid for every single memory access anyway). Obviously, you also need inter-process and inter-CPU synchro, interrupt handling, etc. But all these are already presented in a virtualised form to user-space. Also, if you want the flexibility of a scripting language, you are willing to forego quite a bit of performance in the process. Is the cost of a user-kernel transition really that relevant in this scenario? And if it is, there are mechanisms to mitigate that cost, e.g. pooling requests, deferring, sending to another CPU, etc. I'm a bit appalled by the way they measure the overhead (Section 5 of the article). They say that their CPU rethrottling code runs in "only" 8 microseconds. Well, if compared to the rescheduling interval, it may seem small, 8 microseconds in kernel code is actually a lot. It means 1/125 of a regular millisecond tick. All this just to change the frequency of the CPU? In short, I agree with the objectives (making the OS more extensible and more flexible), but the way they did it seems dangerous and under-optimal.
亲历亲历：曾把 Forth 塞进内核玩票，认为本论文是更务实的路线
我以前曾把某个 Forth 解释器 hack 进 Linux 内核，但只是玩玩，没做任何有用的事，也没接入什么有意思的东西。这篇论文看起来是这类尝试更务实的做法。
davidw查看英文原文
A while ago, I hacked some forth interpreter (I don't recall which one) into the Linux kernel. It was just fooling around though, and didn't do anything useful or hook into anything interesting. This looks like a much more practical approach to that kind of thing.
相关资源
从这篇论文所有 HN 讨论帖的全部评论里整理出来的链接。
历次讨论
- 2014Hacker News 讨论帖100 分 · 50 评
- 2024Hacker News 讨论帖71 分 · 25 评
同领域还值得读
I/O 比 CPU 更快——让我们划分资源并消除操作系统抽象
I/O Is Faster Than CPU – Let’s Partition Resources and Eliminate OS Abstractions
指出在现代服务器硬件上 I/O 速度已接近甚至超过 CPU，传统操作系统抽象反而成为瓶颈。
系统与数据库2019 · 817 分 · 277 评进阶 · 约 30 分钟编辑精选使用 io_uring 的高效 I/O
Efficient IO with io_uring
由 Linux 内核开发者 Jens Axboe 撰写，介绍 Linux 新的异步 I/O 接口 io_uring。
系统与数据库2019 · 426 分 · 96 评进阶 · 约 45 分钟编辑精选线程对大多数用途而言是个坏主意（1995）
Threads Are a Bad Idea for Most Purposes (1995)
这篇 1995 年的文章由 John Ousterhout 撰写，讨论为什么线程对大多数用途而言是坏主意，并主张事件驱动编程通常更简单、更高效。
系统与数据库2017 · 423 分 · 382 评进阶 · 约 25 分钟编辑精选学习型索引结构之论证
The Case for Learned Index Structures
提出把索引看作一种"模型"：既然 B-tree 等结构本质上是在学习数据的分布，就可以用机器学习模型（如回归模型、神经网络）来近似键到位置的映射，从而替代 B-tree、哈希索引…
系统与数据库2017 · 398 分 · 66 评 · 引用 25进阶 · 约 60 分钟编辑精选FoundationDB：一个分布式、解耦的事务型键值存储
FoundationDB: A distributed, unbundled, transactional key value store
介绍 FoundationDB：一个分布式、解耦设计的事务性键值存储。
系统与数据库2021 · 283 分 · 99 评进阶 · 约 90 分钟编辑精选