网络与分布式2018net.in.tum.de
用 Go 编写网络驱动
Writing Network Drivers in Go
进阶 · 约 35 分钟读完前置知识：操作系统与设备驱动基础、内存映射 I/O（MMIO）、Go 语言与 cgo
导读
这篇论文研究用 Go 编写网络驱动是否可行，基于 ixy 项目尝试实现网卡驱动，并与传统 C 驱动开发方式对照。作者发现 Go 在可读性、并发和开发效率上有优势，但在寄存器/MMIO 等底层操作上受限于缺少 volatile 等语义，最终仍需借助 cgo 调用部分 C 代码。它更像一次边界探索：Go 能写驱动，但纯 Go 实现仍有关键障碍。
HN 关注点：Go 是否适合底层系统编程，以及论文中“并非纯 Go”、需用 cgo 绕过底层语义限制的实现细节。
HN 评论精选
这几条评论里：支持 1 质疑 1 补充 2
补充Go 因易读、并发和性能成为网络/分布式系统参考实现的热门语言，并可能在企业市场取代 Java。
最近我注意到越来越多研究者开始用 Go 写网络和分布式系统的参考实现。在我看来这很合理：Go 易读（即便啰嗦）、不需要奇怪的格式化、标准库支持好、并发相对轻松，还能像脚本语言一样运行。它不如 Python/Ruby/Perl 容易上手，但后三者中只有一个能轻松创建原生线程，更别说轻量协程（而有原生线程的那个又鼓励写难读的代码）。如果不做类型理论或特定领域探索，我想不出另一种语言能这么容易上手。Go 的性能也相当好且稳定，JS 是唯一接近的脚本语言，但得受事件循环约束。我一直认为 Go 的杀手特性之一是它让“耍聪明”变得很难。我越来越认真觉得 Go 热度会继续飙升，最多一二十年内会取代 Java 成为企业软件主流。补充：最近让我这么想的例子是 WPaxos 及仓库；公平说 CASPaxos 的 gryadka 是 JS。
hardwaresofton查看英文原文
This is something I've noticed recently -- more and more researchers are starting to write reference implementation code for networking and distributed systems in Golang. In my own head, it makes sense -- golang is simple to read if not verbose, doesn't require crazy formatting, has excellent standard library support, and has relatively painless concurrency, and can be run as a scripting language. No it's not as easy to get started with as Python, Ruby or Perl, but only one of those has easy-to-spawn native threads, nevermind lightweight coroutines (and the one with native threads encourages illegible code). If you're not doing type theory work or very specific exploration in a specific field, I don't know another language that is so easy to get up and running with. On top of all this go's performance is pretty great/consistent as well, JS is the only other scripting language that comes close generally, but then you have to submit to the event loop. I've always thought one of Go's true killer features is how hard it makes cleverness. I'm starting to seriously think Go's popularity is going to continue shooting up. As I always note I think Go will supplant Java as the incumbent in the enterprise software in one or two decades max. [EDIT] - Forgot to include the most recent example that made me think this: WPaxos(AKA WAN Paxos)[0] and the included github repo[1]. To be fair CASPaxos[2] included gryadka[3] which is in JS. [0]: https://cse.buffalo.edu/tech-reports/2017-03.pdf [1]: https://github.com/ailidani/paxi [2]: https://arxiv.org/abs/1802.07000 [3]: https://github.com/gryadka/js
质疑论文并非纯 Go，因缺少 volatile 等底层语义最终用 cgo 调 C，引发对低层系统代码安全语言的讨论。
看起来这不是纯 Go 实现：“我们最初用纯 Go 实现这些函数，并试图通过空 C 调用强制读写，因为 Go 没有 volatile 关键字或我们需要的等价物。结果出现奇怪行为：初始化似乎正常，包括寄存器 getter/setter，但后来程序失败，因为网卡从未设置继续所需的标志。我们花了很多时间但找不到原因。借助 cgo 导入 device.h 和 log.h 中对应函数并替换 Go 函数后问题解决，但由于时间有限始终无法给出确切解释。”这仍是有趣尝试，让我想是否有一天 Linux 很大一部分会用更安全语言写。
pmoriarty查看英文原文
It looks like this is not a pure Go implementation: "We originally implemented these functions in pure Go and tried to force reads and writes through empty C calls as Go does not have the volatile key word or an equivalent for our needs as far as we know. This resulted in strange behaviour: while initialization seemed to work, including the corresponding register getters and setters, the program failed later when the NIC never set flags that were necessary to continue. We invested a lot of time in this specific problem but could not find a reason for this behaviour. With the help of cgo, which enables the use of C code in Go programs, we imported the corresponding functions in device.h alongside log.h of the original C driver and replaced our go functions. This fixed the aforementioned problem though we never were able to provide an exact explanation due to limited time constraints." It's still an interesting effort, and it makes me wonder if we'll ever see a day when a significant portion of Linux is written in a safer language.
补充指出 ixy-languages 项目用多种语言实现驱动，值得一看。
这帮人真是积极得有点疯！:) 看 https://github.com/ixy-languages/ixy-languages#overview
pjf查看英文原文
These guys are so positively insane! :) See https://github.com/ixy-languages/ixy-languages#overview
支持认为用 Go 写驱动可作为理解新硬件的原型开发手段。
至少这是一个有趣且简单的方法，为不熟悉的硬件从头开发驱动，即使最后打算把整个东西移植回 C。
romed查看英文原文
If nothing else this would be a fun and easy way to develop a driver from scratch for unfamiliar hardware, even if you intended to port the whole thing back to C in the end, after it was all figured out.
相关资源
从这篇论文所有 HN 讨论帖的全部评论里整理出来的链接。
历次讨论
- 2018Hacker News 讨论帖12 分 · 0 评
- 2018Hacker News 讨论帖188 分 · 47 评
同领域还值得读
Paxos vs. Raft：分布式共识是否已达成共识？
Paxos vs. Raft: Have we reached consensus on distributed consensus?
重新审视了 Paxos 与 Raft 两种分布式共识算法之间的差异，试图在一个统一的框架下比较它们，并论证二者的相似程度远高于通常的认知，许多所谓的差别只是表述层面的。
网络与分布式2020 · 343 分 · 65 评 · 引用 10进阶 · 约 28 分钟编辑精选Stellar 协议：互联网级共识的联邦模型
Stellar Protocol: A Federated Model for Internet-Level Consensus (2016)
提出 Stellar Consensus Protocol（SCP），一种面向互联网级共识的联邦拜占庭协议模型。
网络与分布式2018 · 301 分 · 61 评专业 · 约 90 分钟编辑精选拜占庭将军问题（1982）
The Byzantine Generals Problem (1982)
这篇 1982 年论文提出并形式化了拜占庭将军问题：在分布式系统中，部分节点可能叛变或故障、通信不可完全信任时，忠诚节点如何达成一致行动。
网络与分布式2018 · 290 分 · 77 评进阶 · 约 75 分钟编辑精选Google 变差了吗？对搜索引擎中 SEO 垃圾的纵向调查
Is Google Getting Worse? A Longitudinal Investigation of SEO Spam in Search
对搜索引擎结果中的 SEO 垃圾内容做了纵向追踪：作者团队在一段时间内持续采集 Google、Bing、DuckDuckGo 等引擎针对商品评测类查询的结果，用分类器识别联盟营销…
网络与分布式2024 · 276 分 · 274 评入门 · 约 45 分钟编辑精选使 CRDT 能够容忍拜占庭故障
Making CRDTs Byzantine Fault Tolerant
Martin Kleppmann 等人的论文研究如何让 CRDT（无冲突复制数据类型）抵御拜占庭故障节点，即部分参与者恶意篡改数据时仍能保证一致性。
网络与分布式2022 · 266 分 · 40 评进阶 · 约 90 分钟编辑精选