1 / 100

FreeBSD 期刊

FreeBSD 中文期刊

警告
除已校对部分外，本项目目前翻译错漏百出，不适合用于生产。
本项目目前处于低维护状态，主要维护者因精力所限仅处理 PR 或新的期刊。欢迎社区通过 PR 贡献力量。

FreeBSD 期刊原文位于：https://freebsdfoundation.org/our-work/journal

基金会书信、读者来信、日历等均不译。

本书部署网站：https://book.bsdcn.org

PDF 文档

使用由提供的脚本：

用于导出本书的 PDF 文档。该脚本使用 Python 3 编写，仅在 Windows 10、FreeBSD 14 上测试过。

具体使用方法见该项目的 README。

或参见 Github 的 Release。

编辑日志

2024.7.9 机器翻译 2024-0506、2024-0102、2024-0304、2023-1112。校对《悼念 Mike Karels》
2024.7.29 校对《基本系统中的 mfsBSD》
2024.7.30 校对《rdist》
2024.8.12 校对《Hashicorp Vault》、《在 GitHub 上向 FreeBSD 提交 PR》
2024.8.14 校对《2024 年 5-6 月来信》
2024.8.15 校对《嵌入式 FreeBSD 面包板》
2024.8.16 校对《提升 Git 使用体验》、重命名为“期刊”，杂志不符合原意。
2024.11.10
- 校对《新的 Port 提交者：oel Bodenmann ([email protected])》
- 重新机器翻译 2024-0708、2024-0506、2024-0102、2024-0304、2023-1112
- 校对《现在用 Webhook 触发我》
2024.11.14
- 校对《FreeBSD 与 KDE 持续集成（CI）》
- 校对《实用软件：使用 Zabbix 监控主机》
- 校对《BATMAN：更优的可移动热点网络方式》
2024.11.15
- 校对《TCP LRO 简介》
- 校对《TCP/IP 历险记：TCP BBLog》
- 校对《FreeBSD 中的 RACK 栈和替代 TCP 栈》
2024.11.16 校对《实用软件：开发定制 Ansible 模块》

2025-789 嵌入式

开启 FreeBSD 开发之路 —— 专访 Igor Ostapenko

Starting FreeBSD Development An Interview with with Igor Ostapenko
作者：Tom Jones

TJ: 通往 FreeBSD 开发之路的有很多因素，有些是通过大学课程，有些是通过工作经验。你是如何了解到这个项目的？最初又是什么吸引你走向操作系统开发的？

IO: 在上世纪九十年代，我在上学期间有机会接触到了几种编程语言和技术。比如，我花了很多时间鼓捣 TR-DOS，小心规划行号（这在我开始用 ipfw 时勾起了回忆），为自己设想的另一个游戏写 DATA 和 GOTO，还尝试过在 MS-DOS 下用中断向量开发常驻程序。因为有这些经历，极简的命令行界面对我来说并不陌生。后来我在大学学习计算机科学时初次接触到 FreeBSD，当时唯一的问题就是要买哪些书。

很明显，掌握 FreeBSD 会很有挑战，但也会非常值得，因为我必须一路补充基础知识。为什么是 FreeBSD？高年级同学推荐它，因为我们整个宿舍的网络都是基于 FreeBSD 搭建的。这是在千禧年初，还延续着上一个十年的惯性，当时 FreeBSD 是网络领域的事实标准。近年来，我更多专注在操作系统开发上。凭借广泛的软件开发背景，我积累了一系列想法，思考如何利用操作系统内部机制来支持更高层的解决方案。

TJ: 你最初是如何迈出修改 FreeBSD 的第一步的？最初又是怎么决定要做什么工作的？

IO: 第一步是准备。我希望能完善自己已有的 FreeBSD 知识，填补空白，形成更系统的认知。一本非常著名的参考书是 The Design and Implementation of the FreeBSD Operating System（《FreeBSD 操作系统设计与实现》），作者是 Marshall Kirk McKusick、George V. Neville-Neil 和 Robert N.M. Watson。

FreeBSD 源码对我来说并不完全陌生，多年来我已经对其结构有了整体印象。但我想要专业的指导，避免错过关键概念、风格细节或结构要点。幸运的是，有 McKusick 主讲的 FreeBSD 内核课程，它帮我节省了很多时间，解答了我的问题，并且在最佳的方式下提供了历史背景来回答“为什么”。另外，George Neville-Neil 的《FreeBSD Networking from the Bottom Up》（FreeBSD 网络体系结构自底向上）课程则进一步完善了我在网络栈方面的理解。

我考虑过先做大项目还是小项目，并和 mckusick@ 以及 kib@ 讨论过。Konstantin Belousov 建议我从小任务入手，比如修复 bug，这事实证明是最有效的方法。我最初处理的是一些最新报告的 pf 漏洞，这又衍生出对 jail 子系统的改进、对 Kyua 的 execenv=jail 测试工具的改进，甚至还开发了一个新的模块 dummymbuf 用于特定的网络测试。结果是，我继续和 Kristof Provost、Mark Johnston 以及其他 FreeBSD 开发者一起推动项目改进。

TJ: 修 bug 是新手进入一个项目的好办法。你对 2025 年的新 FreeBSD 贡献者有没有推荐的入门方向？

IO: 项目官网已经提供了正式的指导和具体方向，例如。我更愿意提出一种替代思路：最好的路径往往是和个人兴趣一致的。

比如，如果有人对学习或使用 FreeBSD 的网络工具或内核模块（如 netstat、route、pf、ipfw、netgraph 等）感兴趣，那么阅读相关文档和手册页的同时，可能会发现可以通过补充示例、重写复杂概念或补充缺失部分来改进它们。如果 FreeBSD 里没有相应工具或模块，那么将有用的程序加入 Ports 或保持其更新，也是非常重要的参与方式。这类项目通常既有趣又有教育意义，因为可能需要更深入地理解 FreeBSD 内核接口。

如果目标是深入理解内核代码，也可以采用类似的方法——选择自己使用或计划使用的功能，能获得更多收益。比如防火墙：理解其规则在幕后是如何运作的，可以给高级用户带来优势；或者对路由机制进行研究，以解决特定问题。可能还需要在内核中实现缺失的功能或 RFC。偶尔也会有把其他平台的方案移植到 FreeBSD 的需求，例如正在进行中的 Netlink 实现，或是 VPP 框架的移植。这些都为进一步改进留下了空间。最终，和现有代码的工作总会揭示出优化机会——减少每单位数据传输或处理的资源消耗，这对所有依赖 FreeBSD 的企业都有利。

如果贡献不止一个小补丁，我建议两个起步步骤：做好功课并沟通。与 FreeBSD 开发者联系的方式很多（见），最基本的是邮件列表，例如。先讨论潜在项目，可以达成方向上的共识，也可以发现是否有人已经在做。对于开源项目来说，准备工作越充分，沟通效果越好。

TJ: 开发过程往往令人望而生畏，还有很多死胡同。你能分享一些捷径，帮助新开发者更轻松地调试和开发吗？

IO: 我认为《FreeBSD 期刊》是一项非常棒的专业经验分享渠道。我建议浏览过往期刊的目录，寻找能填补知识空白或提供新视角的文章。比如，Mark Johnston 的《Kernel Development Recipes》（内核开发秘籍）和《DeBUGGING the FreeBSD Kernel》（调试 FreeBSD 内核），Navdeep Parhar 的《FreeBSD Kernel Development Workflow》（FreeBSD 内核开发工作流），以及你写的《More Modern Kernel Debugging Tools》（更现代的内核调试工具）。这些文章可以快速概览构建系统的功能和一些技巧（比如避免耗时的完整重建），以及如何利用虚拟化或第三方软件提升效率。

要养成项目推荐的良好实践，我建议阅读 Ed Maste 的《Writing Good FreeBSD Commit Messages》（撰写优质的 FreeBSD 提交信息）。迟早也该熟悉 John Baldwin 的《FreeBSD Code Review with git-arc》（使用 git-arc 进行 FreeBSD 代码审查），这个工具大大提升了补丁发布、审查、更新和合并的效率。

在内核网络方面，我建议仔细研究 FreeBSD 的 Jail 和 VNET 功能。如果工作不涉及特定硬件支持，那么基于 VNET 的 Jail 可以大大简化开发时测试新网络功能的过程。它们可以当作轻量级虚拟机网络来测试特定数据包路径或网络栈行为。这比其他方式更简单，即使同一个 mbuf 数据包缓冲在场景中扮演了所有角色，因为数据都不会离开主机。同时，这样的实验场景也可以成为开发新自动化测试的良好起点。Kristof Provost 的《The Automated Testing Framework》（自动化测试框架）文章和相关防火墙测试代码，以及他在 YouTube 上的演讲，都能提供灵感。

此外，投入时间来熟悉源码环境也很重要。内核是一种特殊的软件，它支持多种架构、编译器和特殊场景，预处理器的 ifdefs 并不足以解决所有问题，有些条件甚至是在代码之外解决的。另外，源码中包含一些自动生成的代码，比如系统调用或 VFS 操作的模板。因此，单靠 grep 或编辑器默认功能是不够的。我个人的配置是 Neovim + clangd + intercept-build，效果不错，但最好先了解有哪些可选方案。介绍了如何利用 LSP 来简化代码理解和导航，这对新开发者来说至关重要。

TJ: 感谢你接受采访。最后你有没有给新贡献者的建议，或者想补充的内容？

IO: 也谢谢你。我的总体建议适用于任何有大量志愿者的国际开源项目：保持开放心态和一定的耐心。打个比方，在社区网络中有许多“主机”（贡献者），并不是随时都能通过任何协议访问。每个“主机”都可能忙于自己的工作，网络接口可能已经过载。因此，对我们的连接超时并不意味着严格的拒绝（RST），更可能是需要更多时间来处理我们的 SYN。像电子邮件这样的沟通方式能提供深度缓冲，通常“先到达的请求”可能最后才被考虑，所以礼貌的重发往往是实用的做法。还需要重新设定对延迟的预期，因为存在时区、优先级（工作优先于志愿贡献）或停机（周末、假期等）的问题。

这个网络已经运行了数十年，一些“主机”从早期就一直参与。他们的积累可以帮助我们应对新挑战，给出方向，或提醒我们避免一些尚未显现的问题。同时，新加入的“主机”也能带来新想法或新视角。每位贡献者都为拼图增添了独特的一块。因此，保持开放心态，努力理解别人信息背后的意图，对新贡献者建立更好的连接至关重要。

虽然不是必须的，但如果你能在“带宽”上做到对等（即也能接受外部连接），这将提升整个网络的容量并促进扩展。换句话说，要准备好在自己这边“打开一些端口”，接纳他人的输入。

Tom Jones 是一位 FreeBSD 提交者，专注于保持网络栈的高性能。

Igor Ostapenko 是 FreeBSD 和 OpenZFS 的贡献者，拥有广泛的软件开发经验，涉及导航设备测试系统、企业流程优化解决方案、逆向工程，以及 B2B/B2C 创业项目等多个领域。

撰写有效的 Bug 报告

原文：
作者：Tom Jones

几年前，我们深受敬重的前 FreeBSD 期刊编辑委员会成员 Kristof Provost 写过一篇关于理想 Bug 报告方式的好文章。遗憾的是，Michael W Lucas 总会在年初就用光我们每期讽刺的额度，所以为了避免“讽刺透支”，决定由我改写 Kristof 的原文，以免出现“反讽破产”。

每个系统维护者都有自己偏好的 Bug 报告与改进请求接收方式。由于 Kristof 是 FreeBSD 中 pf 开发的核心人物，他正是为期刊撰写这篇文章的理想人选。

在被要求改写原文时，Kristof 的回应是：

“我无法在完美的基础上再做改进。”

因此，我来重述 Kristof 的原话，并给你一些入门建议，帮助你更快地整理出最重要、最棘手的 Bug。你可以在这里找到他的博文：。

嵌入式 FreeBSD：回顾与展望

原文：Embedded FreeBSD: Looking Back and Forward
作者：Christopher R. Bowman

在过去一年中，我们已经探索了相当多的内容。虽然我猜大多数人运行 FreeBSD 还是在传统的 AMD64 架构 PC 上，但我们研究了一块可运行 FreeBSD 的嵌入式开发板：Digilent Arty Z7-20。虽然价格不算低，但 Arty Z7 提供了与 CPU 相连的 FPGA 结构，这使它区别于价格更低的树莓派或 Beagle Boards。

我们首先讨论了如何获取该开发板的预构建镜像，以及如何通过串口与其通信。在接下来的文章中，我们研究了如何自己构建镜像，并利用 FreeBSD 的交叉编译基础设施为 Arty 板上的 ARMv7 系统编译。这大大加快了开发速度。我们还讨论了如何定制 FreeBSD 的构建，并将其写入 SD 卡，从而生成我们自己的定制镜像。

在学会构建和定制镜像后，我们学习了如何设置 bhyve 实例来运行 AMD/Xilinx 的 FPGA 软件，以便实验 FPGA 结构电路。

当我们有了 Linux 实例后，就研究了构建电路并将其加载到 FPGA 结构中的基本流程。这里涉及了很多细节：我们必须用一种全新的硬件设计语言 Verilog 来创建电路；还要学习如何使用 AMD/Xilinx 工具将电路连接到芯片上的引脚，再通过这些引脚驱动开发板上的 LED。我们使用了一个代码仓库，把这些工作结合起来，最终能在 Linux bhyve 实例中构建电路。最后，我们学会了两种方式将电路加载到芯片中：一种是在系统启动前加载，另一种是在 FreeBSD 内加载。最终，我们看到了闪烁的 LED，就像圣诞树上的灯光。

在让第一个电路成功运行后，我们开始探索了更复杂的硬件，让 CPU 和 FPGA 结构电路之间进行通信。为此，我们使用了 FreeBSD 的 GPIO 系统。但一开始在镜像构建中发现 GPIO 不工作。我们调查了 GPIO 驱动的探测，发现系统缺少该驱动的原因是硬件在 设备树二进制文件 (DTB) 中没有描述。这引出了对 扁平设备树 (FDT) 文件的简短讨论，以及它如何描述许多嵌入式板子的硬件。我们学习了如何修改 FDT 文件，并用 DTC (设备树编译器) 编译生成 DTB，再让 FreeBSD loader 在内核启动前加载定制 DTB。完成这些步骤后，我们终于能在用户态调用 GPIO 系统来切换外部引脚，再次点亮 LED。

在最近的一篇文章中，事情变得更有趣。我们使用了一个 PMOD 模块：双七段数码管显示器。我们在 FPGA 结构中构建了电路，让它能在两个显示器上显示数值，并通过 AXI 总线向 CPU 提供寄存器接口。我们在 FDT 中添加了条目，描述硬件的寄存器接口，并编写了驱动来控制七段数码管的显示。最后，我们使用 Unix 的 sysctl 框架 作为用户态 API 来设置数码管的数值。

至此，我们已经能用 Verilog 设计电路并放到 Zynq 芯片的 FPGA 结构中；我们能构建通过 AXI 总线通信的寄存器接口，让 CPU 能方便地和定制硬件交互；我们能在内核中描述这些硬件，并编写驱动让 FreeBSD 系统与之交互；我们还能从用户空间与这些硬件交互。接下来会怎样呢？

在有了基本的电路构建与 FPGA 部署能力后，我们开始探索如何在 Zynq 芯片的硬件与 CPU 子系统之间进行通信。这开启了广阔的探索与实现空间，但也存在限制。其中一个限制是 带宽和并发性。虽然寄存器接口功能强大且灵活，但带宽有限。CPU 写寄存器的速度有限，尤其当它还要执行其他任务时。目前，我们的硬件带宽受限。对于七段显示器这样的应用很好用，但如果需要带宽密集型任务，它就不够了。

举例来说，视频显示。我们的 Arty 板有 HDMI 输出接口。寄存器接口或许能支持字符显示，但对位图图形就不够用了。一台 24 位色深、1280x720@60Hz 的显示器需要大约 166 MB/s 的数据吞吐。我们显然不可能通过寄存器接口来实现。传统的做法是分配一块内存，CPU 写入数据，显示硬件读取数据。我们需要探索如何构建硬件来直接访问主存，而不依赖 CPU 搬运数据。寄存器接口知识仍然有用，因为 CPU 需要配置参数（比如基地址），但理想情况是硬件能每秒 60 次自动抓取显示缓冲，而无需 CPU 干预。

让 CPU 能描述硬件应读写的内存对象，开启了 Zynq 系统设计的新可能性。这也让我好奇，这种带宽竞争会对双核 Arm Cortex A9 系统产生什么影响。Digilent 还生产另一款基于 Zynq 的板子，和 Arty Z7-20 类似：。它比 Arty Z7 更贵（双核版 399 美元，而 Arty 是 249 美元），但 Zybo 的内存总线宽度是 Arty 的两倍，频率几乎相同。此外，Zybo 提供 6 个 PMOD 接口，而 Arty 只有两个。不过，Zybo 没有 Arduino 外壳引脚。我更感兴趣 PMOD 接口。除此之外，两者基于相同的芯片，不需要新驱动，FDT 基本不变。研究它需要的改动会很有意思。

另外，还可以研究新的 PMOD 模块。在上可以找到很多。我们之前用过 PMOD SSD：七段数码管。Digilent 已经下架了，但我在下架前买了一块。它使用 UART 接口，而 UART 恰好是 Zynq 芯片上的片上外设，可以通过 FPGA 连接到外部引脚。这应该很容易连接。我猜有开源软件能通过 UART 与它通信，实现定位和授时等 GPS 功能。更有趣的是它提供 每秒脉冲 (PPS) 输出。我知道 Poul-Henning Kamp 过去做过一些基于 FPGA 的计时研究，我想看看这是否能应用在这里。

目前我们还没做过中断实验。但让 FPGA 电路生成中断传递给处理器并不难，同时保持一个寄存器来记录 PPS 与当前时间之间的时钟周期数。当中断服务软件运行时，可以读取该寄存器，补偿中断与驱动运行之间的延迟。这可能对 NTP 软件有用。我不敢确定，但这是我感兴趣的探索。甚至有可能实现一个本地 GPS 同步的一类时间服务器。

我手头还有各种 PMOD 模块，比如加速度计、OLED 显示器和 LCD。将它们接入也很有趣。例如，如果你在板子上运行一个 NTP 服务器（也许利用上面描述的硬件提高精度），你可以用 LCD 持续显示原子时间和位置。

差点忘了，Zynq 板子还内置了 模数转换器 (ADC)。这无疑是另一个有趣的探索方向，但可能需要一些外部模拟电路（如信号调理或缓冲）才能传给 FPGA，这可能超出 FreeBSD Journal 文章的范围。不过，研究如何访问这些片上外设也是很有意义的。

当然，你也可以自己构建硬件，并很容易通过 FPGA 引脚连接。我很好奇，如果你能自己设计，你会做什么？

还有一个我原本打算研究但没提到的方向：在 FreeBSD 上运行 Vivado。如果你看过我的一些代码仓库，可能会注意到 FreeBSD 下运行 Vivado 有一些实验性支持。不过看来有人已经先我一步了：Michał Kruszewski 写了一篇详细的。对我来说，这已经够用了，我能在 FreeBSD 上构建和模拟电路。但还不行的是直接从 FreeBSD 主机加载比特流，以及使用 Vivado Logic Analyzer。这两点在我的 bhyve Linux 实例里也不行，不过也许等 FreeBSD 15.0 发布时，我会尝试直通实验。

希望你觉得这些专栏有用。我很欢迎你的意见或反馈。你可以通过联系我。

Christopher R. Bowman 最早在 1989 年使用 BSD，当时他在约翰·霍普金斯大学应用物理实验室地下一层的 VAX 11/785 上工作。后来在 90 年代中期，他在马里兰大学用 FreeBSD 设计了他的第一款 2 微米 CMOS 芯片。从那时起，他就一直是 FreeBSD 用户，对硬件设计和驱动它的软件都有着浓厚兴趣。他在半导体设计自动化行业已有 20 年经验。

会议报告：2025 BSDCan

原文：
作者：Christos Margiolis

今年，我在上做了一场题为的演讲。

我于 6 月 9 日抵达蒙特利尔，比会议早两天，不过当天没做什么，主要是休息。

第二天 6 月 10 日，我乘巴士从蒙特利尔前往渥太华（会议举办地）。一下车就偶遇了 Olivier Certner（olce@），我们一起在渥太华大学附近餐厅吃了午饭——会议和演讲者住宿都在这里——之后办理入住。晚上，我和 Mateusz Piotrowski（0mp@）、Bojan Novković（bnovkov@）、Kyle Evans（kevans@）在 Father & Sons 餐厅喝酒聚餐。在这个常见的聚会点，我们还遇到了会议的其他人。

2025-456 网络

采访 Kajetan Staszkiewicz

作者：Tom Jones

TJ： 你能简单介绍一下你自己以及你与 FreeBSD 的背景吗？

KS： 我叫 Kajetan Staszkiewicz。 1984 年出生于波兰神奇的城市克拉科夫。大约在 8 岁，我在计算机俱乐部接触了 ZX Spectrum 和 Atari 65XE 等 8 位机器。后来父母给我买了一台 Commodore 64。我对这台机器记忆犹新，直到现在我的桌上还摆着一台能正常工作的机器。

1996 年，我们家买了第一台 PC 克隆机（注：IBM PC 兼容机），不久波兰家用用户就能通过拨号连入互联网。但这种方式可持续时间不长。大约 1999 年，我和邻居们决定搭建邻里网络（注：小区或街道搭建的局域网）。大约 15 个人通过悬挂在屋顶到阳台的 10 Mb/s 以太网线共享一家网吧的 115 kb/s 连接。

网络共享由一台运行 IPchains（注：一款网络数据包过滤与地址转换工具）的 Linux 机器来完成，最初由网吧的系统管理员提供，很快就被我们网络里年长的朋友搭建的另一套系统取代。后来我接手管理，用 Perl 写了几段 CGI 脚本，通过 Web 界面管理 DHCP 服务器和流量整形。

2025-123 下游项目

GhostBSD：从易用到挣扎与重生

原文链接：GhostBSD: From Usability to Struggle and Renewal
作者：Eric Turgeon

这篇文章并不是为了呈现技术细节，而是从一个更高层次的角度回顾 GhostBSD 这些年来的发展历程，项目的当下状态，以及我们的后续方向。如你所知，GhostBSD 是一款基于 FreeBSD，用户友好的桌面操作系统。其使命是为那些想要 FreeBSD 强大功能，但不想面对手动设置复杂性的用户，提供简单、稳定和易于使用的桌面体验。在开始这段旅程时，我还是名非技术用户，梦想着有一天会有一款所有人都能使用的 BSD 操作系统。

GhostBSD 的起源

2007 年，我读了 Eric S. Raymond 的《How To Become A Hacker》（如何成为一名黑客）。书中提到了 BSD Unix 是个让有志贡献者学习和成长的地方。这激发了我对 BSD 的好奇心，促使我开始探索 FreeBSD。那时，我正在使用 Ubuntu，心中产生了一个问题：FreeBSD 能否成为像 Ubuntu 一样适合非技术用户的桌面操作系统？当时，我自己也是非技术用户。我只是喜欢 Ubuntu 的简便性，并且好奇为什么 FreeBSD 不能像 Ubuntu 那样。2008 年，这个问题激发了我创建 GhostBSD 的梦想，我开始学习一切我需要的知识来实现这个项目，使 FreeBSD 对我来说变得像 Ubuntu 一样容易上手。

我花了将近两年的时间才理清一切，尝试使用像 FreeSBIE 这样的工具来制作一款 live CD，并寻找一些代码来构建 GNOME。对初学者来说，FreeSBIE 很难驾驭。作为一位讲法语的加拿大人，《FreeBSD 手册》对我有很大帮助，但我的英语水平有限，我强迫自己去学习它。我翻阅论坛和文档，拼凑 GNOME 的构建，常常是更容易把事情搞乱，而不是让它们正常工作。一个有趣的事实是，“GhostBSD”这个名字来自我的妻子。当时，她还是我的女朋友。她提议的这个名字，我就采纳了。我们在 2009 年 9 月结婚，正好是在项目初具雏形的时候。2009 年 11 月，GhostBSD 1.0 Beta 发布，作为一款运行 GNOME 的 FreeBSD 8.0 live CD。它非常粗糙，充满了问题，但为 GhostBSD 后来的发展奠定了基础。来自 FreeBSD 社区的反馈促进了早期的进展。在这个过程中，有一些人加入进来，帮助我学习源代码控制版本管理和其他技术。像 Ovidiu Angelescu 这样的人，通过他的 shell 脚本技巧让我向 SVN 迈进。我学到了很多东西。现在我们使用 Git，但那时一切都是 SVN。

初期阶段

首个版本是 GhostBSD 1.0 Beta，它让用户体验到了 FreeBSD 和 GNOME 的组合。尽管是个不稳定的开始，但它证明了这一概念的可行性。到 2010 年，1.5 版本通过使用来自 PC-BSD 的 pc-sysinstall 工具增加了一款基于文本的安装器，使得设置过程更加简便。那些早期的几年涉及到深入学习 FreeBSD、shell 脚本编程和与像 Ovidiu Angelescu 这样的人合作。我向 Ovidiu 请教了很多 shell 脚本的技巧。2011 年，2.5 版本引入了图形化的 GBI 安装器，基于同样的 pc-sysinstall 后端构建。这个后端至今仍然是核心组件。它的可靠性意味着我不必重新造轮子。这是一个坚持使用有效方法的教训。

大约在 2012 年开始了 NetworkMgr 的基础工作，NetworkMgr 是一款图形化工具，可用来管理以太网和 Wi-Fi 连接。这是朝着提高可用性迈出的第一步，灵感来自 Linux 的 NetworkManager。到 2015 年，我将它从 ghostbsd-build 中提取出来，单独进行优化以作为一款独立工具。2013 年，3.5 版本发生了一个重大转折。GNOME 3 在 FreeBSD 上的发布是笨重且不稳定的，存在延迟和大量资源占用的问题。这种情况与 GhostBSD 的目标相冲突。我们尝试了其他桌面环境，制作了多个带有不同桌面环境（如 LXDE、XFCE 和 Openbox）的 ISO 文件，GhostBSD 的含义——“在 BSD 上运行 GNOME”——面临了身份危机。随着 MATE（GNOME 2 的一个分支）的出现，这次危机得到了挽救。我们转向了 MATE，因为它简单且熟悉：当运行在 FreeBSD 上时，比 GNOME 2 更加轻便。当时，我不确定该如何处理其他桌面环境，因为一些人已经从项目中离开了。我开始放弃所有其他的桌面环境，但 XFCE 仍然作为一种方案保留下来。MATE 成为了旗舰桌面，重新定义了 GhostBSD 对可用性的重视，而非追求炫技。

系统基石的转变

我在 2014 年开始着手开发 Update Station，旨在为 GhostBSD 用户带来图形化更新工具。我原本以为这项工作是在之后才开始的，但在回顾 GitHub 后，我发现大约在那个时候，它已开始成型。最初，GhostBSD 依赖于 FreeBSD 的发布源、分发文件和官方包。曾经有一段时间，我们需要开始为像 NetworkMgr 这样的工具提供更新，这促使我们建立了自己的包仓库。我们的自定义包经常与 FreeBSD 的版本升级发生冲突，产生摩擦，要求我们寻求更好的解决方案。此外，对于 Update Station 的自动化来说，freebsd-update 并不容易实现。freebsd-update 无法满足我们“图形化优先”目标的需求。于是我们开始关注 TrueOS 的做法。我注意到他们使用了 PkgBase，这引起了我的兴趣。他们由 pkg 驱动的操作系统更新承诺带来了图形化自由。

在 2018 年，GhostBSD 18.10 转向 TrueOS，将其作为基石。TrueOS 提供了 PkgBase，让我们可以使用 pkg 工具更新操作系统，并且我们放弃了 freebsd-update。TrueOS 还带来了 OpenRC，这是一款现代的服务管理器，非常适合构建用于管理服务的图形化界面，虽然这个目标最终并未实现。转向 TrueOS 使得能从图形界面使用 Update Station 升级软件和操作系统。对我们来说，这是一次革命性的变化：让我们的用户能够通过 Update Station 升级操作系统。随后，TrueOS 引入了 OS ports，让我们可以使用 poudriere 从 ports 树构建操作系统包，并为更新提供了更精细的控制。

遇到的挑战

TrueOS 于 2020 年关闭了，这给我们带来了压力，需要维系我们所获得的一切。我最初想保留 OpenRC，但维护 ghostbsd-ports 和 ghostbsd-src 上的所有服务变成了一个独立的斗争。那时，我几乎是独自一人维护项目，这耗费了我大量的时间，使我无法专注于改进和管理 GhostBSD。到 2022 年，我放弃了 OpenRC，转而采用 FreeBSD 更简单但可靠的 RC 系统。这样做意味着我可以减少工作量，更加专注于目标。到了 2023 年，维护 OS ports 变得过于繁重。2024 年，我决定将操作系统包的构建从 FreeBSD 维护的 PkgBase 转移到 SRC 中，从而简化了维护负担，并重新聚焦于用户体验。

今年 1 月，我意识到从 STABLE 构建 GhostBSD 对我们的小团队来说太过沉重。在与其他贡献者讨论后，我决定切换回 FreeBSD RELEASE。是的，我们失去了对早期驱动程序的利用，但我们节省了调试 STABLE 变更的时间，获得了更稳定的基础来构建。我并不是说 STABLE 总是出问题，但有时一些变更确实会导致问题。

这些年来，通过做出重大抉择，我尽我所能地管理 GhostBSD，这些选择虽然增加了困难，但也为 GhostBSD 缺失的部分带来了收益。PkgBase 和 OS ports 提供了来自图形界面的操作系统更新，但 OpenRC 增加了额外的工作负担。然而，这也意味着增加了项目的维护负担，超出了项目的处理能力。所有这些最新的变更标志着 GhostBSD 回归其根本，并重新聚焦于可用性，而不是过度复杂化 GhostBSD 的维护。这是一个艰难的教训——保持简单。

当前 GhostBSD 的状况

在我写这篇文章时，我们刚刚发布了 GhostBSD 25.01-R14.2p1。这标志着从 FreeBSD STABLE 切换到 FreeBSD RELEASE，使用 14.2-RELEASE-p1 能提供更好的稳定性。新的 GhostBSD 版本号分解如下：25 代表 2025，01 代表 GhostBSD 补丁，R 代表 RELEASE，14.2 代表 FreeBSD 版本，p1 代表 FreeBSD 补丁。这个版本号旨在为用户明确发布内容，不再让用户猜测版本含义。经过这些最近的变动，我感觉我们现在处于一个很好的位置，能够专注于改进我们的工具。

其中一些工具包括：

NetworkMgr：一款用于以太网和 WiFi 的图形化软件，模仿 Linux 的 NetworkManager。通过简单点击替代命令行的混乱。
Update Station：一款图形化软件，用于软件和操作系统升级，升级前会创建 Boot Environment 的备份。安全第一！
Software Station：一款图形化软件，利用 pkg 安装软件。点击、选择、完成。
ghostbsd-build：用于构建 GhostBSD，包括 Joe Maloney 的 ZFS reroot hack，用于在内存中的读写 ZFS 池实时会话。对于演示和安装来说，速度非常快。

GhostBSD 未来展望

对于 2025 年，我计划记录一些标准操作程序（SOP），以便让更多人能够轻松参与 GhostBSD，希望新的贡献者不需要太多的指导。我将为自己家里的服务器部署一台更快的构建服务器，以便更迅速地构建软件包，当前我正等待 PDU 到货。我还希望完成一款 OEM 友好的安装器，以扩大我们的影响力，重新设计 Update Station 以便在启动时安装更新，并改进 NetworkMgr 与 devd 的集成以提高稳定性。如果可能的话，我还计划为 GBI 添加创建主目录数据集的支持，并且可以选择进行加密。FreeBSD 即将在 2025 或 2026 年提供的 AC 和 AX WiFi 支持将带来更好的连接速度，我对此感到非常兴奋。我们的笔记本电脑非常需要这个。

我不能代表其他贡献者发言，但我们在 GitHub 上有一长串任务。我们确实有一份路线图，可以在 GhostBSD.org 的开发标签下找到它。如果你感兴趣，可以去看看。

从长远来看，我们在期待更多的捐款，以便购买一台 ARM（Ampere）服务器，开始构建 GhostBSD 的 arm64 版本。与此同时，GhostBSD 仍然致力于成为一个完全由图形界面驱动的操作系统，利用 ZFS，这非常适合那些希望享受 FreeBSD 提供的功能但不懂技术的用户。我们正在讨论创建一些桌面组件，逐步替代 MATE，这些组件将更好地与 FreeBSD/GhostBSD 对接，比如一个利用 ZFS 的文件管理器。然而，目前这些讨论还没有形成实质性的成果。

结论

GhostBSD 是一段经历，一连串的选择，从 2009 年的 Live CD 到今天的模样。它起步于一名非技术用户的梦想，逐渐发展成了一个社区项目。每一步，像是定制包、TrueOS、ZFS reroot 实时会话和 PkgBase 都解决了一个挑战。过去的经历教会了我坚韧，当前带来了稳定，而未来邀请你们一同塑造。如果你有兴趣参与其中，请访问 GhostBSD.org。你会找到属于你的位置。

ERIC TURGEON 是 GhostBSD 的创始人和领导者。他还是 FreeBSD ports 的提交者，专注于维护 MATE 和 NetworkMgr 的 ports。Eric 居住在加拿大，自 2000 年代末期以来一直对 BSD 怀有热情。他在 GhostBSD、FreeBSD 的贡献、工作和个人生活之间平衡时间。他的动力来自于让 BSD 更加普及，他欢迎所有人加入 GhostBSD 社区。

BSD Now 与将来

作者：Benedict Reuschling

BSD Now 播客最近庆祝了其第 600 集，这似乎是一个绝佳的机会，让 FreeBSD 期刊的读者深入了解这个长期运行的 BSD 节目的幕后故事。

谦逊的开始

学会走路——连接 GPIO 系统

Learning to Walk–Interfacing to the GPIO System
作者：Christopher R. Bowman

在上篇文章中，我们创建了简单的电路，使主板上的 LED 灯闪烁，并且学习了两种不同方法来把电路加载到 FPGA。遗憾的是，当我们加载电路时，CPU 停止运行了。此外，尽管这有点有趣，但并没有与芯片上的 CPU 进行交互。在本篇中，我们将深入了解 Vivado，学习如何在加载电路时保持 CPU 运行，并探索 FreeBSD 中的 GPIO 系统。

之前，当我们使用 U-boot 或者 xbit2bin 和 FreeBSD 下的 /dev/devcfg 时，我们发现 FreeBSD 停止运行了。我认为发生的问题是处理器的系统停止了运行。原来，我们使用的 FPGA.bit 文件并未包含处理器系统的配置信息。在本期中，我们将修复这个问题。

在如何呈现本期的内容上，我犹豫了一下。从学习的角度来看，最自然的方式可能是使用 Vivado 的 GUI（图形化界面）。然而，GUI 并不适合自动化，原因显而易见——它需要人工运行 GUI。此外，描述 GUI 步骤也既困难又繁琐。幸运的是，Vivado 有两个特性使得我们可以相对轻松地绕过这些问题。在使用 GUI 时，Vivado 工具会生成一个 .jou 文件，这是 GUI 在后台执行的所有 TCL 命令的日志。Vivado 还提供了一个 TCL 命令 write_project_tcl，可以用来重新创建使用 GUI 时 Vivado 创建的项目文件。我通常倾向于使用 .jou 文件，因为我发现这些脚本更简洁、易于理解，而且如果我运行这些脚本，我可以直接启动 GUI，或者使用 write_project_tcl 来写一个项目脚本。脚本似乎也更适合像 git 这样的版本控制系统。

如果我们查看“图 1-1：Zynq-7000 SoC 概述”（来自《UG585：Zynq-7000 SoC 技术参考手册》），我们可以看到有多种外设模块（如 UART、I2C、SPI 等），这些模块可以通过多路复用器连接到外部引脚。该手册的“1.2.3 I/O 外设”部分详细描述了更多的功能。出于我们当下的需求，我们只需要注意到，我们可以相当灵活地将 GPIO 设备的信号路由到芯片上的引脚。如果我们再查看的第 12 节“基本 I/O”，我们可以看到，板上的绿色 LED 与芯片引脚相连，这些引脚通过电流设置电阻接地。如果我们将这些引脚设为高电平，LED 灯就会亮起；反之，设为低电平时，LED 灯就会熄灭。

为了切换这些引脚，我们将使用 Vivado 软件将 GPIO 设备的输出路由到 LED 引脚，从而能让 GPIO 设备控制这些引脚。在开始这段旅程时我并不知道，但 FreeBSD 确实有一款 GPIO 子系统，且有人已经编写了驱动程序，使得这一切能从用户空间使用。

要开始，首先把克隆到安装了 Vivado 工具的 Linux 主机上（在之前的文章中我展示了如何设置 bhyve），然后在仓库根目录下输入 make。如果工具 Vivado 已经正确配置，并且一切顺利，它应该会运行 Vivado，并拉取一个脚本，这个脚本会实例化处理器子系统，并将 GPIO 设备的前四个 EMIO 引脚连接到 LED 引脚。包含处理器子系统将解决我们之前在用 bit 流加载设备时处理器停止运行的问题。

在运行 make 后，查找构建的 zynq_gpio_leds.bit 文件。使用之前介绍的 xbit2bin 程序将其编程到芯片中。

你应该会看到什么也没有发生。虽然不是很激动人心，但至少处理器应该仍在运行。

现在，我们需要使用 FreeBSD 的 GPIO 子系统。输入 man gpioctl 会给出关于可用功能的简洁总结。

以 root 用户，我们可运行 gpioctl 程序来列出可用的引脚：

没能成功吧？是的，我对此也有点惊讶。查看 /usr/src/sys/arm/xilinx/zy7_gpio.c 中的 GPIO 源代码，我看到驱动程序中有 probe 和 attach 函数，但查看我的 ARTYZ7 系统的 dmesg 输出，我没有看到任何表明设备已被发现的内容。仔细看一下 probe 函数：

可以看到，找到设备所需的唯一条件就是 ofw_bus_is_compatible(dev, "xlnx,zy7_gpio") 函数返回 true。

在嵌入式系统中，像大多数 ARM 系统一样，硬件通常不像现代 PCIe 总线那样是自识别的。软件无法自动识别硬件的存在以及其控制寄存器在内存地址空间中的位置。出于这个原因，许多操作系统使用 FDT（Flattened Device Trees，扁平设备树）来描述其设备内存映射。FDT 是文本文件，描述了嵌入式系统的信息，包括其他内容：如有哪些设备存在，以及它们在内存中的位置。这使得软件能够处理各种设备，而不需要硬编码信息。通过使用不同的 FDT，相同的内核通常可以与略有差异的设备兼容。FDT 是通过名为 dtc（设备树编译器）的工具将 DTS 文件（设备树源文件）编译成 DTB 文件（设备树二进制文件）。dtc 提供了选项，可以用来编译 DTS 或反编译 DTB。后者非常有用。例如，你可以请求内核返回它正在使用的 DTB，并使用 dtc 将其转换为文本：

如果我们查找 gpio 部分，我们会看到（其中包括）以下内容：

DTB 中的兼容字符串不是驱动程序所期望的，因此它假设设备不存在。如果你查看 FreeBSD 的启动输出，你会发现内核正在使用 U-boot 提供的 EFI 固件模拟的 DTB。我们可以通过修复 U-boot 提供的内容来更改这一点，但那将需要补丁和重新编译 U-boot。相反，FreeBSD 提供了在内核加载器提示符或使用 loader.conf 变量加载 DTB 文件的功能。你可以使用以下 /boot/loader.conf 变量从加载器加载 DTB 文件：

这可以工作，但还有第三种方法。事实证明，你可以创建 FDT/DTS 叠加文件，这些文件是对 FDT/DTS/DTB 的补丁。我们只需要一个添加正确兼容字符串的 DTS 叠加文件，这样就可以了。以下是我在项目仓库的 dts 目录中包含的 DTS 叠加文件的核心部分，并附带一个 Makefile：

我们可能会在后续的专栏中更详细地查看 FDT 文件，所以这里我不做解释。而是给你此文件的概况。构建完 DTB 叠加文件后，将生成的 DTB 文件放入 /boot/dtb/overlays，并将以下内容添加到 /boot/loader.conf：

重新启动并注意新的 dmesg 输出：

现在我们再次尝试运行 gpioctl 命令，你应该能看到类似如下内容的一行：

我们需要告诉 GPIO 子系统将引脚配置为输出，然后可以尝试切换它：

我会等着。灯光亮起时，请尽量保持坐姿，不要起身跳舞。看看你能否弄明白如何打开其他 LED，然后运行脚本 scripts/blink.sh，并传入参数 2。你应该会看到 LED 按照二进制计数闪烁。

如果你对此有什么问题、评论、反馈和批评，我很乐意听到你的声音。你可通过联系我。

在 1989 年，Christopher R. Bowman 首次在 VAX 11/785 上使用了 BSD，当时他在 Johns Hopkins University 应用物理实验室的地下二层工作。后来，在 90 年代中期，他在马里兰大学使用 FreeBSD 设计了他的第一款 2 微米 CMOS 芯片。从那时起，他一直是 FreeBSD 用户，并对硬件设计和驱动硬件的软件感兴趣。他在半导体设计自动化行业工作了 20 年。

FreeBSD 中对 SYN 段的处理

The Handling of SYN Segments in FreeBSD
作者：Randall Stewart & Michael Tüxen

TCP 连接设置

传输控制协议（TCP）是一种面向连接的传输协议，提供了可靠的双向字节流服务。TCP 连接设置需要交换三个 TCP 段，这被称为三次握手。发起 TCP 连接并发送第一个 TCP 段（SYN 段）的 TCP 端点称为客户端。等待接收第一个 TCP 段的端点称为服务器，服务器响应接收到的 SYN 段并发送一个 SYN ACK 段。当客户端接收到这个 SYN ACK 段时，它通过发送 ACK 段完成握手。

TCP 握手不仅用于同步两个端点之间的状态，包括提供可靠性的初始序列号，还用于通过 TCP 选项协商使用 TCP 扩展。如今的互联网中，在握手过程中（SYN 和 SYN ACK 段中包含）最广泛部署的 TCP 选项是：

最大报文段长度（MSS）选项 MSS 选项包含一个 16 位数字（介于 0 和 65535 之间），它表示发送此选项的端点愿意在单个 TCP 段中接收的最大负载字节数。假设此数字不使用 IP 层和 TCP 层的选项。如果使用了这样的选项，则该数字必须减去选项的大小。这有助于 TCP 发送方避免发送需要在 IP 层进行分段的 TCP 段。
SACK-允许选项此选项宣布发送方能够处理选择性确认（SACK）选项。这在发生数据包丢失时有助于提高性能。
TCP 窗口缩放选项此选项包含一个介于 0 到 14 之间的自然数。如果双方都发送了此选项，则启用接收窗口缩放。这允许使用比 TCP 头格式允许的更大的接收窗口，因为接收窗口在 TCP 头中被限制为 16 位（因此为 65535 字节）。这避免了 TCP 中接收窗口字段的大小限制了 TCP 连接的吞吐量的问题。
TCP 时间戳选项此选项包含两个 32 位数字，通常以毫秒级别编码一些时间信息。它用于提高 TCP 性能。

TCP 使用状态事件机来指定。最初，一个端点处于 CLOSED 状态。当端点愿意接受 TCP 连接（在服务器端），TCP 端点进入 LISTEN 状态。当接收到来自客户端的 SYN 段并回复 SYN ACK 段时，端点进入 SYN RECEIVED 状态。一旦 TCP 端点接收到客户端发送的 ACK 段，TCP 端点进入 ESTABLISHED 状态。可以使用 netstat 或 sockstat 命令行工具来观察这些状态。

应用程序编程接口（API）用于控制 TCP 端点的是套接字 API。程序通常使用监听套接字，告诉 TCP 实现可以在此端点上接受 TCP 连接，并且对于每个已接受的 TCP 连接，程序为每个 TCP 连接使用一个单独的套接字。应用程序可以设置监听套接字的参数，并且大多数情况下这些设置会被接受的套接字继承。本文重点讨论服务器端的 TCP 连接设置。需要注意的是，这一功能适用于所有 TCP 栈（默认的、RACK、BBR 等）。

SYN 洪水攻击

当 TCP 最初实现时，每当接收到一个 SYN 段时，都会为 LISTEN 状态的 TCP 端点创建一个新的 TCP 端点。这需要分配内存，并且导致在 SYN RECEIVED 状态下创建一个新的 TCP 端点。所有必要的信息，包括与接收到的 SYN 段中的 TCP 选项相关的信息，都存储在 TCP 端点中。这个过程没有验证提供的信息、IP 地址和 TCP 端口号。

这会让攻击者向服务器发送大量的 SYN 段，而服务器会不断分配 TCP 端点，直到资源耗尽。因此，攻击者可以进行拒绝服务攻击，因为只要服务器没有更多资源，它将无法再接受来自有效客户端的 SYN 段。攻击者只需要发送 SYN 段，特别是，攻击者不会响应接收到的任何 SYN ACK 段。攻击者甚至可以使用伪造的 IP 地址（即攻击者不拥有的 IP 地址）。

SYN 洪水攻击的目的是使接收方耗尽资源，因此无法提供其预期的服务。在 FreeBSD 中，TCP 栈实现了两种缓解 SYN 洪水攻击的机制：

减少内存分配：当 TCP 端点从 CLOSED 状态转移到 SYN RECEIVED 状态时，通过使用 SYN 缓存减少分配的内存量，如下一节所述。
不分配内存：在处理传入的 SYN 段时，不分配任何内存。通过使用 SYN cookie 来实现，如下节所述。

SYN 缓存

SYN 缓存的初始实现是在 2001 年 11 月加入到 FreeBSD 源代码树中的。它通过不分配完整的 TCP 端点，而是分配一个 TCP SYN 缓存条目（struct syncache，在 sys/netinet/tcp_syncache.h 中定义），来减少 SYN RECEIVED 状态下的 TCP 端点的内存开销。一个 TCP SYN 缓存条目比 TCP 端点小，仅允许存储 SYN RECEIVED 状态下相关的信息。此信息包括：

本地和远程 IP 地址以及 TCP 端口号。
用于执行基于定时器的 SYN ACK 段重传的信息。
本地和远程 TCP 初始序列号。
同步段中对方在 MSS 选项中报告的 MSS 值。

当接收到一个针对监听端点的 SYN 段时，会分配一个 SYN 缓存条目，并将相关信息存储其中，同时发送一个 SYN ACK 段作为响应。如果禁用 SYN cookie 且发生桶溢出，则会丢弃桶中最旧的 SYN 缓存条目。如果收到相应的 ACK 段，则使用 SYN 缓存条目中的数据创建一个完整的 TCP 端点，然后释放该 SYN 缓存条目。SYN 缓存还确保在未及时收到相应 ACK 段的情况下重传 SYN ACK 段。

sysctl 变量 net.inet.tcp.syncookies（默认值为 1）控制着是否使用 SYN cookie，结合 SYN 缓存来覆盖无法分配或查找 SYN 缓存条目的情况。

SYN 缓存是特定于 vnet 的，并且以哈希表形式组织。桶的数量由加载器可调参数 net.inet.tcp.syncache.hashsize（默认值为 512）控制。每个哈希桶中的最大 SYN 缓存条目数由加载器可调参数 net.inet.tcp.syncache.bucketlimit（默认值为 30）控制。还有一个总的 SYN 缓存条目限制，由加载器可调参数 net.inet.tcp.syncache.cachelimit（默认值为 15360，即 512 * 30）控制。当前使用的 SYN 缓存条目数通过只读的 sysctl 变量 net.inet.tcp.syncache.count 报告。

还有一些与 SYN 缓存相关的其他 sysctl 变量。这些变量包括：

net.inet.tcp.syncache.rst_on_sock_fail：控制在无法成功创建套接字时是否发送 RST 段（默认值为 1）。
net.inet.tcp.syncache.rexmtlimit：SYN ACK 段的最大重传次数（默认值为 3）。
net.inet.tcp.syncache.see_other：控制 SYN 缓存条目的可见性（默认值为 0）。

TCP SYN 缓存能让服务器端在最小化内存资源的情况下执行完整的握手。对于 SYN RECEIVED 状态下的 TCP 端点，使用完整的 TCP 端点与使用 SYN 缓存没有功能上的区别。即使是像 netstat 或 sockstat 这样的工具也会报告 SYN 缓存中的条目。

支持额外的 TCP 选项也不是问题，因为 TCP SYN 缓存条目可以扩展。

sysctl 变量 net.inet.tcp.syncookies_only（默认值为 0）可以用来禁用 SYN 缓存的使用。在这种情况下，只会使用下一节描述的 SYN cookie。

为了进一步防范 SYN 洪水攻击，SYN 缓存的实现于 2001 年 12 月进行了增强。在处理接收到的 SYN 段时，服务器不再分配较少的内存，而是将相关信息存储在一个所谓的 SYN cookie 中，并在 SYN ACK 段中发送给客户端。然后，客户端需要在 ACK 段中反射该 SYN cookie。当服务器处理 ACK 段时，所有相关信息都包含在 SYN cookie 和 ACK 段中。因此，服务器可以基于这些信息创建一个 ESTABLISHED 状态的 TCP 端点。通过这种方式，SYN 洪水攻击不会导致内存资源的耗尽。然而，SYN cookie 的生成不能消耗过多的 CPU 资源。如果生成 SYN cookie 的过程过于耗费 CPU，可能会导致另一种拒绝服务攻击：这次攻击的目标不是内存资源，而是 CPU 资源。

在 TCP 头中，唯一可以由服务器任意选择并被客户端反射的字段是服务器的初始序列号。该字段是一个 32 位整数，因此用作 SYN cookie。

在 FreeBSD 中，这 32 位被分割为一个 24 位的消息认证码（MAC）和 8 位，具体如下所示：

3 位用于编码 8 个 MSS 值中的一个：216、536、1200、1360、1400、1440、1452、1460。如果客户端在 MSS 选项中发送的值不在这个列表中，则使用不超过该值的最大值。
3 位用于编码对端是否不支持窗口缩放或使用以下 7 个值之一：0、1、2、4、6、7、8。如果客户端发送的值不在此列表中，则使用不超过该值的最大值。
1 位用于编码客户端是否发送了 SACK-permitted 选项。
1 位用于选择两个密钥中的一个。

MAC 使用一个秘密密钥，该密钥每 15 秒更新一次。当前和上一个秘密密钥都会被保留下来，并根据 SYN cookie 中的位来选择使用哪个密钥。

MAC 的计算包括本地和远程 IP 地址、客户端的初始序列号、上述 8 位和一些内部信息。从 MAC 中生成 24 位，并与上述 8 位结合，构造出 SYN cookie。

当服务器接收到三次握手的 ACK 段时，会验证 MAC。如果验证成功，服务器将根据 SYN cookie 中的信息创建 TCP 端点，该信息提供了 MSS 选项的近似值、窗口位移的近似值以及客户端是否声明支持 SACK 扩展。所有其他相关信息必须从 ACK 段中恢复。这些恢复的信息包括本地和远程 IP 地址和端口号、本地和远程初始序列号、是否使用 TCP 时间戳选项，以及如果使用，当前的时间戳参数。

SYN 缓存与 SYN Cookies 的比较

与 SYN 缓存相比，SYN cookies 的优势非常明显：接收到新的 SYN ACK 段时无需进行内存分配。然而，使用 SYN cookies 也有其缺点：

MSS 被 8 个值近似，所有值都小于或等于 1460。因此，不支持 IPv4 中大于 1500 字节的 MTU。
用于窗口缩放的位移被 7 个值近似，所有值都小于或等于 8。这意味着不支持大于 8 的窗口位移，因此连接的窗口大小会更小。
不支持除了当前广泛部署的 TCP 选项之外的其他 TCP 选项。这使得支持用于协商新 TCP 特性的新的 TCP 选项变得困难。
如果 SYN ACK 段丢失，则不会重新传输 SYN ACK 段，发起连接的端点必须重试发送其 SYN 段。

使用 SYN 缓存没有这些限制，并且是透明的，但需要为 SYN RECEIVED 状态下的每个 TCP 端点分配内存。

SYN 缓存与 SYN Cookies 的联合使用

仅使用 SYN cookies 相比使用 SYN 缓存能更好地缓解 SYN 洪水攻击，但也带来了一些功能限制。因此，FreeBSD 的默认配置启用了 SYN 缓存，并与 SYN cookies 结合使用。这意味着，当接收到一个 SYN 段时，系统会生成一个 SYN 缓存条目，而发送的 SYN ACK 段则包含一个 SYN cookie。如果 SYN 缓存的一个桶溢出，系统会认为这是由于正在进行的 SYN 洪水攻击导致的，因此暂停使用 SYN 缓存。在此期间，仅使用 SYN cookies。

这一额外功能于 2019 年 9 月引入，在正常操作期间提供 SYN 缓存的优势，但在 SYN 洪水攻击发生时也能提供 SYN cookies 的改进保护。

RANDALL STEWART（）是一位操作系统开发人员，拥有 40 余年的经验，并自 2006 年起成为 FreeBSD 开发者。他专注于传输协议，包括 TCP 和 SCTP，但也涉足操作系统的其他领域。目前，他是一名独立顾问。

MICHAEL TÜXEN（）是明斯特应用技术大学的教授，同时也担任 Netflix 的兼职承包商，自 2009 年起成为 FreeBSD 源代码提交者。他的研究重点是传输协议，如 SCTP 和 TCP，以及它们在 IETF 的标准化和在 FreeBSD 中的实现。

FreeBSD 2024 年秋季峰会

链接：Fall 2024 FreeBSD Summit
作者：Alice Sowerby

我参加了 2024 年秋季在 NetApp 圣何塞校园（Santana Row）举办的 FreeBSD 峰会。此次活动让我有机会与 FreeBSD 社区建立联系、交流思想，并讨论正在进行的项目。我的主要目标是通过演讲以及非正式的交流，强调直接资助项目在 FreeBSD 基金会工作中的作用。

面对面交流让我深刻体会到亲自参与的重要价值。我与许多人进行了富有成效的讨论，探讨了基金会资助项目的影响，同时也看到了大家对 FreeBSD 在笔记本电脑使用方面的兴趣，这也是我演讲的核心内容。

在活动期间，我遇到了几位有趣的人，他们分享了自己使用 FreeBSD 的经历以及对该系统的抱负。同一行程中，我也有幸见到了 Framework 团队，这让我更好地了解了基金会笔记本电脑项目的背景。

我于 11 月 8 日（星期五）进行了演讲，Learning as We Grow: Managing FreeBSD Infrastructure and Laptop Projects at The FreeBSD Foundation（边成长边学习：FreeBSD 基金会的基础设施与笔记本项目管理）。听众提出了很多深思熟虑的问题，我也非常感激有机会分享我们如何构建和资助这些项目的见解。

让我印象特别深刻的是 Marshall McKusick 的演讲 The History of the BSD Daemon，它为我们提供了有关 BSD 历史的有趣见解。他还带来了既往 BSD 会议的 T 恤，并将其赠送给与会者，这一温馨的举动令所有人感动。

Santana Row 为此次峰会提供了一个充满活力且便利的环境。NetApp 大楼宽敞而友好，使得与人会面和进行有意义的讨论变得十分容易。活动组织得井然有序，这种环境也促进了富有成效的交流。

自参加峰会以来，我已经感受到了由此建立的联系和讨论带来的益处。这些讨论和获得的见解帮助塑造了正在进行的项目，并强化了以社区为驱动的发展努力的重要性。

参加 2024 年秋季的 FreeBSD 峰会让我有机会与 FreeBSD 社区互动、分享知识并加深合作。此次活动突显了 FreeBSD 基金会投资的价值，并为讨论 FreeBSD 的未来提供了极好的平台。我期待着继续这些交流，并在峰会带来的势头上进一步发展。

Alice Sowerby 在打造团队和培养科技领域领导者方面拥有丰富的经验。

2024-1112 虚拟化

2024-0910 内核开发

嵌入式 FreeBSD：探索 bhyve

原文链接：Embedded FreeBSD: Digression into bhyve
作者：Christopher R. Bowman

在之前的两篇文章中，我们讨论了我一直在实验的 Digilent Arty Z7-20 开发板。我觉得这是一块很有趣的开发板，因为它不仅可以切换主要引脚与外界进行接口，而且你还可以将自己的电路集成到开发板中，并将其与处理器进行接口。然而，要做到这一点，你需要使用 Xilinx/AMD 的软件来配置和编程芯片。Xilinx 将这个工具套件称为 Vivado，你可以从他们的网站上免费下载一个适用于 Zynq 芯片的版本。

那么，缺点是什么呢？肯定有什么潜在的问题，对吧？其实有两个问题。首先，Vivado 只有 Windows 和 Linux 版本。其次，下载的文件本身就有 110GB。多年来，我在 Mac 上通过 VMWare 运行 Linux 版本，效果还不错。但最终，我的虚拟机有好几个不同版本，每个版本的软件安装情况都不同。这些虚拟机非常大，早期的版本大约是 30GB，最近的一些安装版本甚至达到了 75GB。假设在几台机器上有几个版本，那么总空间开始变得非常庞大，而且我也很难追踪哪个版本是最新的。

于是，我决定简化并集中管理。我希望将所有下载的原始厂商工具存储在我的网络文件服务器上，这台服务器自然运行 FreeBSD，拥有数 TB 的 ZFS 存储空间。毕竟，我不能依赖于厂商继续提供这些旧版本的工具，尤其是在他们更新到新版本后。这是可以理解的，但作为一个爱好者，我的工作进度并不总是与厂商的进度同步，因此我希望确保能够保留原始工具下载文件。我希望我的主目录以及我的工作文件和项目都存储在我的网络服务器上，这样它们可以从我所有的机器上访问，并像任何其他数据一样进行备份。我希望所有解压并安装好的厂商软件都存储在我的文件服务器上，而不是存放在我的虚拟机里。这样，我可以利用 ZFS 的强大功能对厂商软件安装进行检查点保存。我的虚拟机只是一个轻量级的 Linux 安装，任何我想要实验的 Linux 版本。如果我需要升级或创建新的虚拟机，我知道里面没有任何工作内容，所有东西都在我的文件服务器上，所以我只需要安装一个新的基本系统，其它所有内容仍然保存在文件服务器上。我无需复制或重新安装厂商工具。由于最近我家计算环境的升级包含了一台 16 核 128GB 内存的 FreeBSD 机器，我希望在这台机器上运行这些工具，以应对我的设计规模变大，可能需要数小时来合成的情况。作为额外的好处，我得到了一个设置，其他人如果想要复制我的工作，只需要一台 FreeBSD 机器即可。

目前似乎有两种基本的方法。我可以尝试让安装程序在 FreeBSD 的 Linux 仿真环境下运行，并在我的 FreeBSD 机器上本地运行这些工具，而不需要 Linux 虚拟机。如果能够实现，那将是非常棒的！但我不确定是否能做到，也不清楚可能会遇到哪些问题，或者需要多长时间才能弄明白，而我当时正处于几个项目的中间。这个方法看起来确实是最好的，我很想知道是否有人已经成功实现，或者有谁想尝试，但我选择了一个我认为会涉及较少工作量且更有可能成功的方法。我听说过 bhyve，决定进行调查。如果我能运行一个支持 Vivado 的 Linux 版本的虚拟机，我认为那将是最简单的。只用了一个晚上阅读和另一个晚上实验，我就惊讶地成功运行了。

我从 FreeBSD 手册开始。它真的是一个很棒的资源，感谢所有帮助使其如此出色的人。对如何使用 FreeBSD 作为主机操作系统做了很好的介绍。在大多数情况下，我从那里和互联网上的其他一些地方拼凑出了一个设置。为了设置，我创建了网络的基本主机配置：

我正在使用中的说明，因为我不想麻烦地设置 grub。使用 UEFI 帧缓冲还允许我通过 vnc 导出 Linux 显示。如果我使用 FreeBSD 主机，或者从网络上的任何其他机器，都可以连接。不过，也许我应该再考虑一下安全性问题。

我下载了一个 CentOS 的 ISO 版本，是在 RedHat 终止它之前的版本，然后我使用以下虚拟机配置进行安装：

通过这种方式，我得到了一个 4 核心、32GB 的虚拟机，ISO 镜像 /u1/ISOs/CentOS/CentOS-7-x86_64-DVD-2009.iso 被挂载为客户机中的 CDROM。这样，我可以运行一个标准的图形界面安装 Linux，过程非常直接。我是在裸 zvol 上运行的：/dev/zvol/zroot/vms/centos7。这样做是为了我可以使用 ZFS 快照随时对虚拟机进行快照（最初是在干净安装后），以便随时回滚。如果我将虚拟机虚拟磁盘放在 ZFS 文件系统上，快照会应用到该文件系统中的任何内容，而不仅仅是虚拟机虚拟磁盘映像。我还听说使用裸 zvol 可能更快。回想起来，我本可以为每个虚拟机虚拟磁盘映像使用一个单独的数据集，并在该数据集上使用文件作为虚拟磁盘映像，而不是使用 zvol。如果每个虚拟机有一个数据集，快照仍然只会应用于虚拟机。我不确定哪种方法更好，随后的阅读让我对 zvol 与文件支持的速度产生了疑问。我的工具运行时间还不长，因此我还不太关心每一分性能的提升。我还听说，对于支持的客户操作系统，NVMe 设备比 AHCI 硬盘设备更快，但我还没有进行实验。如果这个问题变得严重，创建一个新的虚拟机就很容易了，因为我的数据和安装并不依赖于虚拟机。

安装了 CentOS 后，我配置它通过 NFS 挂载我的 FreeBSD 机器上的主目录，然后我进行了 Xilinx Vivado 工具的安装。这是一个图形界面的安装，过程很简单。我只需要确保安装路径是 NFS 挂载的目录。考虑到文件操作的量，我原本预期这个过程会非常痛苦，但实际上它相当快，尤其是考虑到安装后工具的体积达到了 66GB。要知道，我有一个非常快速的本地网络。我不打算编辑工具的安装，但是我创建了一个快照——这也是为了安心。我不想再重复安装一次。

当我申请 Vivado 许可时，我复制了 Linux 客户机报告的以太网 MAC 地址。这个地址似乎在重启时保持稳定，但我希望能弄清楚如何配置它，以确保我的虚拟机中的 MAC 地址始终与 Vivado 许可中的 MAC 地址匹配。

现在，我有了一个相当通用的 CentOS 虚拟机，安装了 Vivado，可以通过 VNC 从我本地网络上的任何机器访问。到目前为止，我还安装了一个 15 年前的 Linux 版本的《文明：天赋神权》（Civilization: Call to Power），以便在我的 FPGA 构建编译时玩。这让我惊讶于它运行得多么流畅（以及我有多么上瘾）。

尽管大部分功能都运行得很好，但与我之前在 Mac 上使用 VMWare 的设置相比，还是有一些不同之处。首先，VMWare 支持将文件系统传递到主机。NFS 挂载基本完成了相同的功能，我没有注意到太多的速度惩罚，但我必须在 Linux 中配置，而不是在 VMWare 的图形界面中配置。这不是一个大问题——我对此非常适应。真正让我希望能有 VMWare 解决方案的地方是复制和粘贴。如果我在 Linux 客户机的图形界面中选择了一些内容，我无法轻松地将其复制并粘贴到运行 VNC 查看器的机器上。这偶尔是个痛点，但由于我在 Linux 中使用的用户文件系统都是从 FreeBSD 挂载的 NFS，我可以像从 FreeBSD（或任何其他挂载它们的机器）一样轻松编辑这些文件。因此，我几乎不在 Linux 下进行编辑或工作。大部分时间，我只是在 Linux 的 VNC 会话窗口中运行 Vivado 编译，其他所有工作都在外面进行。总体来说，这个方法还是相当有效的。

在下期文章中，我们将开始使用 Vivado 构建我们的第一个电路。

如果你对这些内容有反馈、抱怨或批评，我很乐意听到你的声音。你可以通过联系我。

Christopher R. Bowman 自 1989 年在约翰霍普金斯大学应用物理实验室的 VAX 11/785 上首次使用 BSD 以来，一直在使用 FreeBSD。他在 90 年代中期使用 FreeBSD 设计了自己在马里兰大学的第一个 2 微米 CMOS 芯片。从那时起，他一直是 FreeBSD 的用户，并对硬件设计及其驱动的软件非常感兴趣。他在半导体设计自动化行业工作了 20 年。

实用软件：实现无纸化（Paperless）

原文链接：
作者：Benedict Reuschling

在疫情最严重的时候，我一直待在家里，日子基本上和其他日子没什么区别。时间过得很慢，环顾四周，我意识到我的房间变得相当凌乱。尤其是我的工作桌旁，堆积的书籍、笔记、信件和其他纸张已经开始争相堆到桌面上。我决定做点什么。我戴上耳机，开始整理、归类、扔掉，并清理到我的桌面变得整洁。这种成就感在全球危机时期格外强烈。受到这一感觉的激励，我决定开始扫描那些纸张，减少堆积的纸张数量。

我几个月前买了一台移动扫描仪，它通过 USB 连接，并使用一些专有但高效的扫描软件。这个扫描仪的大小不亚于一个擀面杖，能够扫描一张纸。由于当时有时间，我开始一张一张地扫描每张纸，为每个生成的 PDF 添加描述和日期，然后继续扫描下一张。虽然这很繁琐，但最终我完成了。之后整理这些文件又是一个漫长的任务：税务、保险、合同、收据、账单（包括已发送和已收到的）、记录、证书等，都需要放入正确的目录中。

但扫描软件只有 32 位，几年前整个扫描设备停止工作了——恰好在另一堆纸差点要倒塌的时候。于是，是时候寻找替代方案了。几个月前，我发现了 textproc/py-ocrmypdf。这款软件本质上是重新扫描 PDF 并将文字从图像中提取出来，使其成为可以提取和搜索单个单词的文本。它通过模式识别来识别单词和语言，结果出奇的好。我将其应用于现有的扫描文件，现在我可以对文档进行全文搜索，找到例如我参加 BSDCan 2014 时的机票费用等信息。

2024-0708 存储与文件系统

使用 ZFS 原生加密保护数据

原文链接：Protecting Data with ZFS Native Encryption
作者：Roller Angel

ZFS 原生支持加密数据集，能让你轻松地使用行业标准的密码套件来保护数据。与磁盘的全盘加密相比，将数据集加密的主要优势在于，当未使用数据集时，可以将其卸载，而全盘加密要求在静止状态下加密时，磁盘必须关闭。请记住，ZFS 原生加密有加载和卸载密钥的概念。仅仅卸载加密的数据集是不够的，你还必须卸载与该数据集关联的密钥。如果密钥仍然处于加载状态，数据集可以被挂载并且数据将可用。卸载密钥会使挂载操作失败。加载密钥是挂载数据集的前提。嵌套的子数据集会继承其父数据集的加密密钥，但这并非必须。即使父数据集使用不同的加密设置，也可以使用不同的加密密钥和密码套件。最后，更改密钥就像在数据集上执行 zfs change-key 命令一样简单。

这些是开始使用的基础概念。

为新创建的数据集启用加密参数，再设置密钥格式就足够了。如果未指定加密密码套件，则默认使用 aes-256-gcm。默认值可能会随着未来新增密码套件而变化。现有数据集的加密属性是只读的，无法修改未加密的数据集的属性来启用加密。要指定加密属性，你需要了解有哪些参数可用。我建议阅读 zfsprops 手册页，你可以输入命令 man zfsprops 来查看。我还建议阅读 zfs-load-key 的手册页。对于我们的第一个加密数据集，我们将使用默认的密码套件、口令密钥格式，来创建一个名为 secrets 的数据集。我使用的是我实验室中创建的 FreeBSD jail 机器，名为 alice。实验室中的所有 jail 都位于名为 lab 的 zpool 上。我已将叫 zroot 的 zpool 分配给 jail。在 jail 中，我必须使用完整路径 lab/alice/zroot 作为 zpool 名称，以便在其中创建数据集。作为对比，我的笔记本电脑上，我可以直接使用我的 zpool 名称并在那里创建数据集。以下是创建加密数据集的命令，适用于 alice jail 和我的笔记本电脑。同其他 ZFS 数据集一样，设置挂载点是一个好主意，但请记住 ZFS 是个分层文件系统，因此不要使用现有路径作为新数据集的挂载点。

alice jail:

我的笔记本：

在运行 zfs create 命令后，提示我输入一个足够长的口令。现在，我有了一个已挂载的加密数据集，可以在其中存储需要保护的数据。当数据集处于挂载状态时，我可以像使用其他未加密的数据集一样使用它。当我完成机密数据的添加后，我可以通过输入命令 zfs unmount -u lab/alice/zroot/secrets 一次性卸载数据集和密钥。要解密、重新挂载数据，只需运行命令 zfs mount -l lab/alice/zroot/secrets。这会提示我输入口令，加载密钥，然后挂载数据集。如果在卸载命令中省略参数 -u，只会卸载数据集，密钥仍然会保持加载状态。数据集仍然可以通过 zfs mount lab/alice/zroot/secrets 挂载，而无需输入口令。要在数据集已卸载后卸载密钥，我运行 zfs unload-key lab/alice/zroot/secrets。现在，之前的挂载命令将失败，因为密钥没有加载，并且我未提供参数 -l 来让 ZFS 在挂载之前加载密钥。要加载密钥且允许挂载数据集，我会运行 zfs load-key lab/alice/zroot/secrets。系统会提示我输入口令，之前的挂载命令现在会成功，因为密钥已经加载。要检查密钥是否已加载，可以查看数据集的属性。当我运行命令 zfs list -o name,mountpoint,encryption,keylocation,keyformat,keystatus,encryptionroot lab/alice/zroot/secrets 时，会显示一些有用的属性。KEYSTATUS 列显示为 "available" 时，表示密钥已加载。要查看所有数据集属性，可以使用 zfs get all lab/alice/zroot/secrets

接下来，我在 secrets 数据集下创建一个嵌套的数据集，并使用不同的密码套件和密钥格式。这次，我将使用密钥文件而非口令。要创建使用密钥文件的数据集，我首先需要生成密钥并将其存储在文件中。我通过输入命令 dd if=/dev/urandom bs=32 count=1 of=/media/more-secrets.key 来完成。由于密钥文件要求长度为 32 字节，因此我使用了 bs=32。输出路径选择 /media，因为我在此路径下挂载了一个便携式 USB 驱动器，还使用 dd 命令生成了密钥文件，再将其直接存储到驱动器上。这样，当我卸载密钥并卸载和移除 USB 驱动器时，密钥文件就不会留在我的机器上。我建议将密钥文件存储在多个 USB 驱动器上，以防某个 USB 驱动器损坏。现在，密钥文件已经生成，我可以通过运行命令 zfs create -o encryption=aes-256-ccm -o keyformat=raw -o keylocation=file:///media/more-secrets.key -o mountpoint=/secrets/more-secrets lab/alice/zroot/secrets/more-secrets 来创建使用 AES-256-CCM 密码套件的嵌套数据集。查看这个新数据集的属性时，我可以看到 ENCROOT 列设置为 lab/alice/zroot/secrets/more-secrets。我可以使用与 secrets 数据集相同的方法来卸载和卸载密钥。当我拥有更多数据集和密钥时，我可能想考虑使用 zfs unload-key -a 卸载所有密钥，或使用 zfs unload-key -r lab/alice/zroot/secrets

如果我后来决定 more-secrets 数据集中的数据不需要单独的密钥文件，而是希望它继承父数据集 secrets 的设置（即从自定义生成的密钥文件切换到之前配置的口令），我只需要运行命令 zfs change-key -i lab/alice/zroot/secrets/more-secrets。再次查看属性，注意到 ENCROOT、KEYLOCATION 和 KEYFORMAT 都已经发生了变化。然而，密码套件不会改变，因为密码套件只能在数据集创建时设置。由于 more-secrets 是包含在 secrets 中的，它将作为卸载 secrets 数据集的一部分被卸载。虽然挂载 secrets 数据集不会自动挂载 more-secrets，但它需要单独挂载。不过，由于它们共享相同的密钥，所以密钥只需要加载一次。要切换回使用密钥文件，我运行命令 zfs change-key -o keyformat=raw -o keylocation=file:///media/more-secrets.key lab/alice/zroot/secrets/more-secrets。如果我想永久销毁 more-secrets

最后，我想分享的一点是关于加密数据的备份。如你所见，ZFS 原生加密能轻松地使用加密来保护数据。加密数据集的快照可以以加密形式传输到不受信任的备份服务器上。没有密钥，远程备份服务器就无法挂载该数据集。可以使用 zfs send 命令的参数 --raw 来实现这一点。有关更多细节，我建议阅读 zfs-send 的手册页，以了解其工作原理，然后获取《ZFS Mastery: Advanced ZFS》一书，深入研究具体细节，并学习一系列技巧，以进一步提升你的 ZFS 技能。

希望你喜欢这篇操作指南，并且开始使用 ZFS 文件系统提供的原生加密来保护你的敏感数据。

Roller Angel 大部分时间都在帮助人们学习如何使用技术实现他们的目标。他是一位热衷于 FreeBSD 系统管理的 Python 爱好者，喜欢学习开源技术（尤其是 FreeBSD 和 Python）解决问题的神奇方法。他坚信人们可以学习所有他们愿意去做的事情。Roller 总是在寻找创造性的解决方案，享受解决问题的挑战。他有很强的学习动机，喜欢探索新想法，并保持技能的敏锐。他喜欢参与研究社区，并分享自己的想法。

TCP LRO 简介

原文链接：
作者：Randall Stewart、Michael Tüxen

TCP 大型接收卸载（TCP Large Receive Offload，TCP LRO）是一种特定于协议的方法，用于降低接收 TCP 段（TCP segment）时所需的 CPU 资源。它也是实现特定的，本篇文章介绍了它在 FreeBSD 内核中的实现。在任何给定时刻，TCP 通常用于单向通信，尽管 TCP 提供了双向通道。例如，当使用 TCP 作为传输协议的应用协议是请求/响应类型（如 HTTP）时，即是这种情况。

TCP LRO 可采用多种方式降低所需的 CPU 资源，包括：

合并到达确认（acknowledgment，ACK），向 TCP 栈发送单个大的扩展 ACK，而非多个较小的 ACK。适用于 TCP 端点主要发送用户数据的情况。

2024-0506 配置管理对决

基本系统中的 mfsBSD

作者：SOOBIN RHO
原文链接 https://freebsdfoundation.org/our-work/journal/browser-based-edition/configuration-management-2/mfsbsd-in-base/

mfsBSD 是一款基于 FreeBSD 的内存操作系统。

mfsBSD 的不同之处在于，它是完全运行于内存的 FreeBSD 实例——因此叫做 mfs（memory file system，内存文件系统）。所以，这意味着当我们在使用 mfsBSD 时，不会对现有的磁盘设备造成任何干扰。例如，我们可以将其用于本地服务器和云服务器的故障排除①。在邮件列表中搜索 mfsBSD，看看人们是如何解决各种问题的，实乃一大趣事。我个人最喜欢的应用场景是在仅有单个磁盘的设备中安装 FreeBSD，如果因某种原因无法使用 FreeBSD 安装介质，我就会：先制作 mfsBSD 镜像、将这个镜像安装到磁盘设备上、启动 mfsBSD、最后运行 bsdinstall。示例如下：

首先，构建 mfsBSD：

然后，将 mfsBSD 写入磁盘设备：

启动到 mfsBSD，然后执行 bsdinstall：

mfsBSD 能够把整个 FreeBSD 系统都加载到内存。加载完成后，就可以对原始磁盘进行修改任意了，因为现有的 mfsBSD 文件都运行在内存中。正如 Matuška 在其白皮书（2009 年）中所述，“mfsBSD 是个工具集，能创建基于 mfsroot 的短小精悍版 FreeBSD，它将所有文件都放在内存。”②

mfsBSD 简史

mfsBSD 的作者是 Martin Matuška（[email protected]）。回顾 mfsBSD 存储库的提交日志，他首次提交于 2007 年 11 月 11 日，大约是在 FreeBSD 7.0 BETA 的发布同期。“这个项目[mfsBSD]基于 Depenguinator 项目的想法”，Depenguinator 是 Colin Percival 在 2003 年创建的项目，旨在为仅提供 Linux 发行版的专用服务器远程安装 FreeBSD③。Matuška 想开发 FreeBSD 6.x Depenguinator 的功能实现，这就是 mfsBSD 的起源。

自此以降，Matuška 维护着，用于分发 mfsBSD 的镜像。他已经在 GitHub④ 上维护了十七年的 mfsBSD，一路修复了无数 bug，并添加了对 zfsinstall、/usr tar 压缩包的支持等。在此期间，mfsBSD 知名度不断增长，

2023 年 5 月（即此篇文章写作的前一年），这个谷歌编程之夏（Google Summer of Code，GSoC）项目开始了把 mfsBSD 集成到基本系统中的尝试。

谷歌编程之夏

这一切是如何开始的呢？当时，我正在阅读黑客新闻（可能我正在拖延大学作业）。这是我第一次知道谷歌编程之夏（GSoC）。那里的某条热门评论说 FreeBSD 项目也参与了。有趣的是，评论中只字未提其他事情，好像其他事情都是不言自明的。

我立刻被吸引住了。关于 FreeBSD 最令我惊讶的是：macOS 衍生于 FreeBSD，而且 Netflix 也在其 CDN 中使用了 FreeBSD。谷歌编程之夏的申请流程包括提交项目提案。原则上要求申请者从各组织的项目创意列表中寻找项目主题（除非你有自己的打算）。我看了看列表，对我来说，mfsBSD 项目最有趣，因为其他项目创意似乎比我能接受的内核开发更遥远。

在给我的导师们发了封电子邮件后，我收到了 Joseph Mingrone([email protected]) 和 Juraj Lutter（[email protected]）的回复，并进行了简短的 Zoom 通话。几周后，我收到了谷歌编程之夏的录取通知。然后，我们进入到了所谓的社区粘合期（community bonding period）。在这期间，所有的贡献者和导师们相聚集于虚拟会议，总共开了半个小时，所有人都进行了自我介绍。那天是 2023 年 5 月 12 日（星期五）。

基本系统中的 mfsBSD

三个月又二十二天，将 mfsBSD 集成到基本系统中的项目终于完成了，历经许多的反复调试（很多 Bug 是通过谷歌搜索和翻阅所有过去的 GitHub 问题来解决的），测试（使用我的两台笔记本电脑 Thinkpad T440 和 P17 来运行 shell 脚本），并且我向导师提出了许多问题。一整套的三个补丁提交到了 Phabricator⑤。

简单地说，第一个提交“mfsBSD: Vendor import mfsBSD（mfsBSD: 引入 mfsBSD）”将 mfsBSD 集成为 contrib/mfsbsd。主要提交“release: Integrate mfsBSD image build targets into the release tool set（发行：将 mfsBSD 镜像构建目标集成到发行工具集）”：在 release/Makefile 中添加了目标 mfsbsd-se.img 和 mfsbsd-se.iso（作为 release/Makefile.mfsbsd）。最后一次提交“release(7): Add entries for the new mfsBSD build targets（release(7): 为新的 mfsBSD 构建目标添加条目）”在 share/man/man7/release.7 上添加了相应的条目。这意味着，现在我们可以在构建所有 FreeBSD 安装介质（如 cdrom、dvdrom、memstick 和 mini-memstick）的同时，在相同的发行版 Makefile 中使用 make release WITH_MFSBSD=1 构建 mfsBSD。

现在，正在对补丁集进行审查。mfsBSD 之前位于 FreeBSD 发布工具链以外，仅生成 release 版本。我的设想是将这个补丁集作为基本系统的一部分，来提供 mfsBSD 镜像，并通过调用 cd /usr/src/release && make release WITH_MFSBSD=1 来构建定制 mfsBSD 镜像，然后在 /usr/obj/usr/src/${ARCH}/release/ 创建 mfsbsd-se.img 和 mfsbsd-se.iso。

参考文献

①. Matuška, Martin. (2022). FreeBSD 在 Hetzner 专用服务器上——VX Weblog。[在线] 参考：
②. Matuška, Martin（2009）。mfsBSD 工具集，用于创建基于内存文件系统的 FreeBSD 发行版。[在线] 可在以下网址找到：
③. Colin Percival（2003）。Depenguinator — FreeBSD 远程安装。[在线] 可在以下网址找到：
④. Matuška, Martin（2024）。mmatuska/mfsbsd。[在线] GitHub。可在以下网址找到：

SOOBIN RHO 是南达科他州奥古斯塔纳大学的大四学生。他出生于韩国，但在迪拜长大，最终选择在美国上大学。他现在是美国合众银行网络安全部门的兼职员工。在毕业后，他将成为一名信息安全分析师。自 2023 年谷歌编程之夏以降，他一直是 FreeBSD 的贡献者。

悼念 Mike Karels

我们对 Mike Karels 的离世深感悲痛，他是 BSD UNIX 历史上的一个重要人物，更是在 FreeBSD 社区中备受尊重的成员，同时也是 FreeBSD 项目的副发布工程师。Mike 在 BSD 系统开发和发展方面做出了卓越贡献，并在 FreeBSD 项目留下了不可磨灭的印记。

Mike 的愿景和奉献精神对塑造我们今天所知道并使用的 FreeBSD 起到了关键作用。他的精神将永远激励和指导我们在未来继续努力。

我们向 Mike 的家人、朋友和所有认识他的人表示慰问。我们将深切怀念他。

请参阅其亲属准备的待办事项，了解他不可思议的一生。

无需送花，Mike 的亲属更倾向于将其捐给基金会，以资助日后的 FreeBSD 项目。

有关 Mike 的文章

BSD 老将：Michael J. Karels 逝世，享年 68 岁

2024 年 5-6 月来信

作者：Michael W Lucas
原文链接：https://freebsdfoundation.org/our-work/journal/browser-based-edition/configuration-management-2/we-get-letters-may-june

亲爱的来信专栏，
我的雇主有数十台服务器，但我不知道有多少操作系统。其中一台的运行时间比我都大，没人敢碰。但有个大聪明把一本电脑杂志落在了洗手间，被老板发现了。现在老板的脑瓜里，已经把“配置管理（configuration management，又称组态管理）”当成了化解我们全部问题的万金油，但数据中心真正需要的是背包核弹（核背包）。我该怎样才能让他明白，这些工具并不适合我们这样的环境？
“我已经注定要失败了，问你也无济于事。”

亲爱的失败者，

“问我也无济于事。”似乎系统管理员可以承受的痛苦有限，或者说他们失败的程度有限。失败并非是可以溢出的整数值。失败是一种社会构建，而你的失败已经完全确定。

我们都看过配置管理的推广。只需一个命令就能部署专用的高度优化过的服务器！用简单的 Playbook（译者注：Playbook 是 Ansible 的配置文件）就能调整计算云端！从一个服务器无缝透明迁移到另一个服务器！容器！对于那些什么都不懂的人来说，非常棒。但大多数系统管理员的工作环境用“巴洛克”（译者注：指复杂繁琐）来形容再合适不过了，甚至可以说是“史前文明”。我发现只有自己亲自在耕耘过的土地上，等待三叶草长出后，自己才能有一片绿地——绝非草坪，草坪是对气候施暴（译者注：人工草坪和羊都会威胁生态环境）。除非你养羊、或山羊——但如果你养任意品种的山羊，你的草坪都不会长久。这表明善行也是荒漠化的中介。此外，有谁愿意在安装数据中心之前等待三叶草呢？把那堆被夷为平地的幼儿园的废墟推平，继续过你的日子吧。

配置管理是一个仅存在于广告中的理想，且往往会制造麻烦而不是解决麻烦。没错，加拿大冰球联盟可以通过 DevOps 管理整个 Web 服务器集群，以动态应对全国人民同时观看纪念杯决赛时增加的负载，据说他们还可以通过 DevOps 增建更多心理健康设施，以应对伦敦骑士队输给萨吉诺精神队（他们甚至不是加拿大人）时的巨大失落感。而你？可能就不那么幸运。动态采购是动态调配的先决条件，而你显然缺乏都不具备。

你可以部署配置管理，但不要以恶意合规的方式来做。跳过那些过于理想化的手段来管理整个服务器集群。你没法只用一把椅子、一根鞭子和一把火焰喷射器来管理服务器集群。但系统中那些痛苦的部分是可以控制的。

配置管理是系统管理工具。因此，使用它来满足你的需求。从少量系统开始。配置一个带访问权限的管理账户，让你的管理系统可以 ping 这些主机。恭喜你——你已经实现了恶意合规！这满足了你被管理的需求，但不符合你的管理需求。

每台服务器都是一片独特的雪花，尽管是一种会感染的雪花。当你开始控制这些系统时，从相对简单的东西开始，已是已知的最佳值，在 Unix 变体中亦基本一致。关于这个问题有句陈词滥调：“一切问题都是 DNS 问题。”问题总是 DNS 问题，因为系统管理员不懂 DNS，并且在 DNS 服务器变化时未同步更新 /etc/resolv.conf。我总是从这开始的。你不仅要在初步配置管理下使系统生效，还要对当前的 DNS 配置进行审计，作为该项目的先决条件。你的经理会喜欢它。将你的主机按操作系统分组，并将它们的解析器纳入你的管理范围。如果你充满善意，请为这个文件写一下注释。

恭喜！你已经控制了 DNS 解析。它会经常变化吗？希望不会。但是你现在可以轻松地进行更改了。如果你希望别人认真对待你，你必须始终进行威慑，因此请安排：每月运行配置管理来更新 resolv.conf。

你可以合法地声称你的主机已经在配置管理下运行，但你还没有利用它让生活变得更轻松。看看另一个常见的服务，每个主机都有但通常配置不一致的：SSH。你的组织可能有像“禁止基于密码的认证”这样的规则。如果没有，等到发生安全事件再议。绝不能浪费一场好危机！锁定 SSH 并确保它保持锁定状态的最简单方法是将 sshd_config 纳入集中管理。是的，每个操作系统都有自己定制的 sshd_config，因为在集成软件之前，Unix 的维护者们总要将其改造成自己喜欢的样子，但管理系统使用模板来对抗这种不卫生的行为。你可能已在上班路上睡着的时候，背诵过默认的 sshd_config，所以请确保你的管理配置与默认配置看起来截然不同。

任何想着“我把默认选项注释掉就好了”的系统管理员在看到此处时，大脑就会瞬间惊醒。

慢慢的，你就可以将大部分环境都纳入你的掌控之下。对已管理服务的更改将变得微不足道。你的同事们会看到这一点。关于更改未管理服务的讨论将变成“我们如何将这个服务纳入管理？”利用这些讨论来实施环境中的必要更改，或者为自己争取第四台更好的显示器。毁灭是一种社会构建，但通过配置管理，你可以将其转变为一层保护壳，或者是一面攻城锤。至少，你可以分享那份痛苦。

很少会提及部署配置管理，但有一个可怕的副作用：谁掌控了环境，谁就掌控了权力。任何变更都必须经过你。人们无法在那台面向公众的服务器上永久启用密码验证，但这并不意味着他们不会向你抱怨。他们会期望你参与问题解决，没人能够在变成一位问题解决高手的情况下活下来。那无法消除的声誉污点只会让你赢得公司替罪羊的称号。

幸运的是，你知道山羊意味着什么。开始放牧吧。

有关于 Michael 的问题？请发送至。

Michael W Lucas 是 Networking for System Administrators 等多本著作的作者，他还犯下了许多其他危害人类文明的罪行。其中的专栏文章集《Dear Abyss》（亲爱的深渊）即将在 Kickstarter（译者注：美国的一间众筹平台，该文章集在）上连载，他预谋的证据确凿。详情请访问。

嵌入式 FreeBSD 面包板

作者：CHRISTOPHER R. BOWMAN
原文链接：

我已使用了近三十年的 FreeBSD。最开始，在上世纪九十年代初我安装了 FreeBSD，因为我能够非常轻松地用它的软件包系统，来安装当时用于设计首批硅芯片所需的免费 CAD 软件版本（译者注：freeCAD 诞生于 2001，时间不符，此处不是 freeCAD），其精度高达 2 微米（即 2000 纳米，这里不是错别字）。不必自己配置编译 3-4 个软件包，这意味着我在一个晚上就可以安好系统，然后在家里的地下室进行芯片设计。在那之前，我需要驱车赶往大学，然后每天在昂贵的 Sun 工作站上花费数个小时工作到深夜。现在我在家就能完成所有工作，而且工具的运行速度更快！虽然我会编程，但我一直把 FreeBSD 用作计算基础，从未参与过社区开发。现在，我想要用 FreeBSD 做一些东西，而不仅仅是用 FreeBSD 完成我的工作。

市面上有大量的小型嵌入式板，其中某些享有极高的声誉——比如树莓派及其各种衍生版本。对我而言，这些小型嵌入式板最有趣的地方，就在于它们能够与外部世界进行接口通信。这样的小板大都带有从 CPU 引出的 GPIO 引脚，因此可以与各种真实世界的东西进行交互。但我本质上是一名硬件工程师，我真的很想做硬件。虽然我的职业发展还不错，但我仍然没有那几百亿美元去建立自己的晶圆厂，或者花费数百万美元去购买电子设计自动化（EDA）软件来设计自己的芯片。如果你想要制作自己的，现在有一些有趣的项目，但我在找到它们之前就走上了这条路。我一直在想，我的确可以购买树莓派或其他一些出色的板子（比如 Arduino 等），但我会用它们做什么呢？因此，我不断地阅读有关这些板子的资料，但从未尝试过。最后，我找到了适合我的板子。

2024-0304 开发工作流与集成

FreeBSD 与 KDE 持续集成（CI）

原文链接：KDE CI and FreeBSD
作者：Ben Cooksley

自 2011 年 8 月以降，KDE 就开始实施 CI（Continuous Integration，持续集成）系统，且持续改进着。自此，系统已经大幅演进，增加了对多个 Qt 版本（大多数 KDE 软件所使用的工具包）以及多个平台的支持。

得益于容器的普及，能在多个操作系统上可靠地运行所有这些构建。为了理解容器解决了哪些问题以及 CI 系统可扩展性中的挑战，我们需要回顾 KDE CI 的起点。

系统起初由简单的 Jenkins 配置——在同一服务器上进行构建。然而，随着更多项目接入，构建需求增加，需要更多的机器。

这带来了一个难题：KDE 软件的构建需要其他 KDE 库——通常是最新版本的。这意味着仅增加构建机器是不够的，还需要确保最新的依赖项始终可用。

由于构建应用程序所需的全部依赖项链时间较长，因此无法每次重新构建全部内容，这就需要共享构建产物。经过快速评估，选择了 rsync，它使系统运作良好。

引入 FreeBSD

到 2017 年，CI 系统需要支持新的平台，于是系统中加入了 FreeBSD。FreeBSD 的早期支持较为简单，在 Linux CI 工作节点上采用虚拟机运行。每台虚拟机单独配置，包含构建 KDE 软件所需的所有依赖项。

虽然这种方法确保了 KDE 软件在 FreeBSD 上的可靠构建，但系统的扩展性较差，因为需要逐台更新构建器。这一方法成功地保证了 KDE 软件在 FreeBSD 上的构建可靠性，也改善了 FreeBSD 上 KDE 团队的开发体验。

在添加 FreeBSD 支持的同时，我们还在 Linux 构建中引入了 Docker。能够首次创建一个可在所有构建器中分发的主配置，方便了 CI 系统的变更发布，标志着基于容器的构建时代的开始。唯一的缺点是 Docker 仅适用于 Linux，如何在其他平台上再现这一流程成为一个问题。

随着构建能力的扩展，出现了一些新问题。构建偶尔会随机失败，日志显示文件缺失和符号链接损坏，但随后检查发现文件存在，之后的构建可顺利完成。问题在于：原子性（Atomicity）。

在新硬件下，构建速度加快，增加了 rsync 在文件上传时，而另一个构建节点下载构建产物的概率。解决方案是使用 tar 包的构建产物，以原子操作发布完整的文件集。此方法与 SFTP 协议（用于不支持 rsync 的平台）结合，CI 系统恢复了稳定运行，资源和支持平台也有所增加。

但手动维护机器的问题仍然存在。迁移到 Gitlab 和 Gitlab CI 后，构建节点由于累积的代码检出和构建产物迅速耗尽磁盘空间，测试留下的进程也会占用 CPU。而 Linux 上的 Docker 构建不存在这些问题。

我们探讨了多种解决方案，如改进 Gitlab Runner 的“shell”执行器、清理构建产物的 cron 作业，以及基于 FreeBSD Jail 的解决方案，但均无法复现 Linux 上 Docker 的体验。

发现 Podman

某天早上，我们在研究 FreeBSD 的容器化选择时偶然发现了 Podman 及其搭档 ocijail。这正是我们在基于 Docker 的 Linux 设置中习惯的功能，但现在能在 FreeBSD 上实现了。

这意味着之前遇到的残留进程和需要手动清理的构建产物问题都能得以解决。此外，我们还可以利用标准的 OCI（Open Container Initiative，开放容器计划）注册表（例如 Gitlab 内置的容器注册表）来把 FreeBSD 镜像分发到所有构建器上，从而解决了单独维护每台机器的问题。

首要困难是构建一款能用的镜像。对于 Linux 系统来说，Docker 和 Podman 非常成熟，有详细的文档说明基础镜像及其包含内容。但在找到适合的 FreeBSD 基本镜像后，我们以为只需添加 FreeBSD 包仓库，安装所需软件包即可。

然而，在容器中首次构建时，CMake 报告无法找到编译器。我们认为这很奇怪，因为 FreeBSD 系统通常预装了编译器。经调查，我们发现 FreeBSD 容器与正常的 FreeBSD 系统的主要区别在于：容器经过大幅精简，默认未包含编译器。

经过数次迭代，我们添加了编译器和 C 库开发头文件，从而在 FreeBSD 容器中成功构建了首款 KDE 软件。虽然我们认为一切顺利，但后续构建依然失败，因为需要额外的开发包。经过多次迭代和安装更多 FreeBSD 软件包后，我们终于完成了多个关键 KDE 软件包的构建。

接下来我们将注意力转向 Gitlab Runner 的“辅助镜像”，用于执行 Git 操作和上传构建产物到 Gitlab。尽管可以在 FreeBSD 上运行 Linux 二进制文件，但我们希望能在 FreeBSD 上原生构建。仿照 Gitlab 的方法构建镜像后，顺利得到了预期的结果。

冒险之旅的乐趣部分开始了：深入 Gitlab Runner 和 Podman 的内部机制。首次将 Gitlab Runner 连接到 Podman 时，构建遇到报错“unsupported os type: freebsd”。

在 Gitlab Runner 代码库中发现，Docker 需要检查远程 Docker（或在我们的例子中是 Podman）主机的操作系统类型。我们对 Gitlab Runner 进行了补丁和重建，解决了此错误，但紧接着又出现了类似的报错：“unsupported OSType: freebsd”。进一步修补后，又遇到一个更严重的错误，尤其是使用 Go 语言编写 Gitlab Runner 时：

显然，要使该功能正常工作需要进行更多修改，但由于容器化构建的潜力，我们继续研究该问题。最终，我们找到了导致失败的代码：

我们发现 Podman 的守护进程崩溃，从而中断了请求。这个问题可以通过尝试运行 podman inspect 进行复现。原因归结为专门用于“inspect”操作的代码调用了 Linux 专用的构造。经过又一次补丁后，我们的 podman inspect 不再崩溃，终于成功启动了第一次 FreeBSD 构建。

在 FreeBSD 上运行构建

首次构建仍然失败（由于 Gitlab Runner 与非 root 用户的容器交互的已知问题），但我们在 FreeBSD 上已成功运行了构建。

你可能以为此时我们可以为所有 KDE 项目推行基于 FreeBSD 的容器化构建了。然而，最终测试发现 FreeBSD 容器的网络速度远低于预期，与 FreeBSD 主机相比明显较慢。

幸运的是，这个问题不是新问题。我们预计会遇到此问题，原因是大型接收卸载（LRO）。简单地更改配置后，最终我们达到了预期的性能，可以投入生产。

今天，KDE 使用 Podman 和基于 ocijail 的容器来运行 FreeBSD CI 构建，有 5 台 FreeBSD 主机处理构建请求。构建中使用了两台不同的 CI 镜像——分别适用于 Qt 5 和 Qt 6 的版本，确保 KDE 软件可以从零开始构建，并可选地通过所有单元测试。

自从从 FreeBSD 专用虚拟机迁移到 FreeBSD 容器化构建后，我们从每周甚至每日对构建器进行维护，逐渐减少到每隔几周维护一次，几乎没有收到开发人员的投诉。

我们已成功向上游了我们提交编写的补丁，现在所有人都可以使用这些补丁构建自己的 CI 系统。

容器化的优势——尤其对持续集成系统来说——不可低估。所有维护系统的团队都应考虑容器化，尽管初始的迁移成本较高，但回报非常值得。

Ben Cooksley 是一名会计师和计算机科学家，因其在 KDE 社区的贡献而闻名，尤其是在系统管理和基础设施方面。他对系统管理的兴趣源于对系统运作和集成的好奇心。

2024-0102 网络（十周年）

FreeBSD 接口 API（IfAPI）

原文链接：
作者：Justin Hibbits

如某些人所知，瞻博（Juniper）使用自己定制的网络栈，该网络栈基于 FreeBSD 开发的长期分支，因此在表面上它看起来与当前的 FreeBSD 网络栈相似，但实际上存在诸多差异。当前 FreeBSD 网络栈中的某些状态在 Junos 中并不存在，反之亦然。

BATMAN：更优的可移动热点网络方式

原文链接：
作者：Aymeric Wibo

在广阔的网络协议领域，有一种协议脱颖而出，作为一个多功能且自适应的竞争者：BATMAN，即 Better Approach to Mobile Ad-hoc Networks（随建即连网络优化方案）。在大城市的无线电波中，BATMAN 能让设备在网状网络中无缝通信，却无需让任何一台设备了解整个网络拓扑。

今夏，我参加了谷歌编程之夏 (GSoC)，并将内核模块 batman-adv（提供了 Linux 对 BATMAN 协议的支持）移植到了 FreeBSD。谷歌编程之夏是个学生在暑期参与开源项目的计划，谷歌为学生提供津贴，并由导师监督。对我而言，我的导师是那位唯一无二的 Mahdi（或 Mehdi，取决于你问他是星期几）Mokhtari，即 mmokhi@。他是位非常有风度的人，我非常感激在谷歌编程之夏的旅程中有他的指导！

现在，使用 batman_adv（FreeBSD 上等同于 batman-adv

2023-1112 FreeBSD 14.0

FreeBSD 容器镜像

原文链接：
作者：Doug Rabson

OCI 容器引擎，比如和，需要容器镜像。容器镜像是个只读目录树，通常包含一款应用程序及其支持文件和库。容器镜像在容器引擎上运行时，会创建该镜像的可写副本，并在某种隔离环境（如 jail）中执行该应用程序。通过注册中心分发容器镜像。注册中心存储镜像数据，提供了一个简单的 REST API 来访问镜像及其元数据。由对注册中心的 API、镜像格式和元数据进行标准化，基本上取代了早期的 Docker 格式。

新的 Ports 提交者：oel Bodenmann ([email protected])

采访者：TOM JONES
原文链接：New Ports Committer: Joel Bodenmann ([email protected])

TJ： 你好，Joel，欢迎你加入 FreeBSD 项目。你能为我介绍一下你自己以及你喜欢从事的技术项目吗？

JBO： 我是一名电子工程师，主要从事嵌入式系统。通常，我喜欢处理被设计用来执行特定任务的系统，而非通用计算。

TJ： FreeBSD 并不以嵌入式系统开发著称，你尝试过在 FreeBSD 上进行工作和项目吗？

JBO： 我不敢苟同。我之所以选择 FreeBSD，正是为了将其用作嵌入式系统开发平台。虽然在过去几年，“嵌入式”世界发生了巨变，但我通常处理的嵌入式系统是资源相对较低、实时性强的系统（即基于微控制器的系统典型设备，CPU 速度 < 120MHz；RAM < 128kB）。因此，这些系统并非直接设计用于运行 FreeBSD；而且实际上，也不会运行什么 Linux（亦不符合要求）。

你仍然需要一台（桌面）主机系统进行实际的开发，以及周围的支持基础设施。我经常参与的上述嵌入式项目，从首次会议到部署产品可能要花几年的时间。我对作为开发平台的 Linux 一个不满是，Linux 生态系统始终处于不断动荡的状态。你在基于 Linux 的系统上配置的开发工作流程和环境，仅仅几个月后，就被迫更新，这就需要重新验证所有的工作流程。

FreeBSD 以其稳定性和连贯性而闻名。FreeBSD 不会因为旧的系统/组件“不够好”而回炉再造新的系统/组件，而是努力使这些系统和工具具有可维护性和可扩展性，从而大大减少了开发系统管理的开销。

对于某些项目，我的确需要一个非微控制器系统，微控制器系统与之通信（即长期数据记录，编排等）。在这种情况下，FreeBSD 具有等同的优势：你设置和验证系统一次。然后，在接下来的几年里，只需执行几次较小的维护任务，而对于基于 Linux 的系统来说，我从来不知道第二天会遇到什么情况。

粗略总结，基本上是，我喜欢把时间花在实际开发和工程上，而不是因为底层的 init 系统、音频子系统、虚拟化和最流行的容器系统（或类似系统）在两年内不断变更而一直在更新、调试和重新验证我的开发平台。这么说，FreeBSD 符合所有要求。自从我将所有服务器、网络基础设施和工作站迁到 FreeBSD 后，我从来没有怀疑过，在第二天进入办公室后，我的开发基础设施是否仍然可以正常启动和工作。FreeBSD 非常可靠。

TJ： 你是否已经在 ports 中有了特定的关注领域？

JBO： 到目前为止，我主要致力于处理“伸手就能解决的东西”，这样做的想法是让我熟悉 ports 系统的基础知识以及工作流程和基础设施。与此同时，这也释放了更有经验的 ports 提交者的资源，让他们可以将精力专注于更复杂的事务。

随着我熟悉程度的增加，我希望在接下来的一年里承担涉及很广的任务，比如更新拥有许多使用者的 ports 库。

因此，我对你的问题的回答是：不，我尽我所能地帮助。我毫不怀疑，随着经验的丰富，我很快就会找到一些更复杂的工作要做：🙂:

TJ： ports 非常庞大，许多小工具就可以完成繁重的工作。到目前为止，你做过的一些容易实现的 port 是什么？你有什么建议可以帮助其他人找到容易实现的 Port 和更容易的第一个 port 吗？

JBO： 就我个人而言，迄今为止，我认为有两种容易实现的目标情境：

PR，这些补丁已经获得维护者的批准，并将补丁更新到新的上游次要版本的 port。在这里，我建议刚开始时避开那些涉及大量用户的“基础”port，以减少触发大规模故障的风险。我的理由是简单的上游次要版本的升级几乎不会出错，并且维护者倾向于小心地避免破坏他们的 port，并且他们已经具有经验，知道要特别注意他们的上游相关事项。
引入新的 port 的 PR。这些 PR 往往是“低优先级”，因此压力相对较小，不必急于将它们落地。此外，我认为这是了解 ports 框架提供的各种不同系统和机制的绝佳途径，这些我可能之前尚未接触过。

截至目前，我所做的工作：我有意尝试触及各个领域的各种 port。我不专注于特定类别或类型的 port。相反，我尝试处理一些我知道依赖于我尚未使用过的东西的 port 的 PR。这是熟悉各种 Mk/Uses/* 脚本的绝佳方式。

TJ： 当你展望 FreeBSD 的未来时，从维护者的角度来看，你认为项目的主要优先事项应该是什么？

JBO： 我认为使 FreeBSD 对各种用户如此具有吸引力的重要原因之一是我们通常遵循更传统的原则。FreeBSD 项目倾向于采取“稳扎稳打”的方式，而不是不断跳上最新的炒作列车不断重新造轮子。当然，这种方法也有缺点。例如，ports 框架可能缺少一些被现代标准视为“基本”的功能，例如子包，可选的推荐安装等。但我认为，正是因为这些事情不被匆忙对待，我们最终得到了一款更稳定和易于维护的系统。

因此，与其回答你的问题并给出需要完成的具体步骤和目标清单，我强烈建议忠于这种方法。最终会证明任何美好的事情都会发生，但通常会以一种非强制的方式发生，以便进行适当的设计、实施和测试，从而有效利用我们有限的人力。

只要不急于求成，不强求进展，就能规避很多子弹。在我看来，“慢就是顺，顺就是快”这句话在这儿适用。

TOM JONES 是一名致力于保持网络堆栈快速运行的 FreeBSD 提交者。

2023-0910 Port 与软件包

CCCamp 2023 旅行报告

原文链接：https://freebsdfoundation.org/our-work/journal/browser-based-edition/cccamp-2023-trip-report/
作者：TOM JONES
译者：ChatGPT & Natsufumij

前言

随着十月的温暖（结束），我注意到今年的第一场霜降临。我并不是在抱怨天气（这已经成为一项全民运动），秋天的到来令人愉悦。我再次可以穿上连帽衫，而阳光时而出现则是一个美好的惊喜。

在整个夏天的一个星期中，我沉浸在地球上最炎热的户外领域之一。

Chaos Communication Camp（CCCamp）是由 Chaos Computer Club（CCC，混沌计算机俱乐部）每四年在德国举办的为期五天的户外黑客节。2023 年是该活动的第七届，也是我第三次参加，（之前）分别是 2015 年和 2019 年。

黑客营地是一种难以言喻的体验，我很难准确传达出这个活动所带来的强烈力量。CCCamp 在德国北部的 Mildenberg Brick Work Park（米尔登堡砖厂公园）集结了来自欧洲和世界各地的 6,000 名黑客，共同庆祝艺术、文化、社会、环境并持续不断地打扰计算机。我们在八月中旬的五天中，都相聚在距离柏林北部约一小时的地方。

场地

这个营地是关于技术及其对我们生活影响的讨论场所。尽管这个说法有待斟酌，但这是一个在在野外聚会和狂欢一周的绝佳借口，同时可以玩弄新旧计算机、无线电设备以及各种不同的照明系统。

主题内容

演讲和研讨会按照主题分为五个地区的村庄：Bits und Baeume、Digital Courage、Milliways、N:O:R:T:X，以及 Marktplatz。Bits und Baeume 主持关于数字化、技术和环境的演讲和研讨会，位于砖厂的半路处，有一座通风的帐篷。Digital Courage 主持以德语呈现的数字权利内容，而 Milliways 则专注于安全相关内容和有关硬件的研讨会。

每个舞台都是露天场地，都设有一些迷彩网或防水布，提供阴凉和一些遮雨的地方。与前几年闷热的马戏团帐篷相比，露天场地是一大改进。尽管 EMFCamp 也使用这种帐篷风格，但英国的天气与中欧的天气有很大的不同，对于 EMFCamp 来说，这样的帐篷更加合适。

然而，露天场地的缺点是在演讲时缺乏给与会者全面庇护的设施。我曾因早早被占据的阴凉地点而放弃了几场演讲。当我们迎来了预期中的雷暴和随后的降雨时，演讲被取消并最终重新安排。

CCCamp 的内容涵盖了令人难以置信的广泛主题。你可以了解现代计算对环境的影响以及摆脱化石燃料的途径，也可以在阳光下使用海藻和盐水制作蓝晒图，或者制作用于 LORA 卫星的收发信机。如果你能在重新安排后找到的话，甚至可以学习如何重新利用“退役”的租赁电动滑板车。Puppet 展示了一场出色的表演，说明了它们接管基础软件的动作，为废弃设备赋予新生。

然而，预定的内容只是 CCC 活动发生的事情的冰山一角，很多奇迹都发生在其他地方。硬件黑客村再次现场展示了他们的硬件黑客巴士，这是一辆装满了研讨会材料和焊接电烙铁的巨大的再利用巴士。硬件黑客村每天从早上 10 点一直持续到深夜，不停地进行研讨会。这一次他们如此拥挤，以至于他们拒绝了那些“太依赖笔记本电脑”的研讨会，为他们提供了专注于拆卸和重新组装物品的空间。

灯光和音乐

到了晚上，整个场地真正变得生动起来。村庄将黑暗视为一种个人侮辱，并在活动的几十年里不断增加 LED、聚光灯和激光的武器库。太阳落山时，活动现场充满了灯光秀，各个村落通过独特的音乐表演、音箱阵列和 DJ 演出增添了会议的热闹氛围。

砖厂有一些建筑和中央基础设施被改装成令人印象深刻的照明装置。每晚，老工厂的烟囱上都会用激光写上信息。中央的“小山”（工厂里的一个旧的观测和装载站）装满了十几台巨大的烟雾机，可以用一堵烟幕覆盖 Marktplatz 周围的区域。这堵烟幕然后被激光和聚光灯照亮。穿过这个带有灯光和烟雾的地方，让你穿过一堵厚厚的墙，能见度很低，进入一个烟雾和灯光共同作用的区域，使世界增加了一层深度。

甚至在湖的中央漂浮着一个巨大的迪斯科球。

除了灯光和音乐之外，CCCamp 今年再次推出了一款活动徽章。徽章本身是一款基于无处不在的 ESP32 的全功能微控制器平台，这是一款高速双核系统，具有 WiFi 和蓝牙功能。在此基础上，徽章团队创建了一个带有大量电容触摸输入、环绕着 LED 的接口板、一个时尚的圆形屏幕、扬声器和音频输出的徽章。

今年的徽章，Flow3r，旨在成为一个音乐创作设备。过去的两次活动分别推出了一款智能手表和一款软件定义无线电。而今年，CCCamp 有意使技术更易于接近和娱乐化。徽章有两个音频输出插孔和扬声器，并附带了一些出色的音乐玩具演示。

具备这种易用性，徽章赋予了无限的创造力。Flow3r 徽章支持通过音频插孔进行 IPv6 网络连接，这是一种超越使用微控制器 WiFi 或蓝牙的步骤。

徽章创新

在多年来为复杂的工具链写软件的酷炫徽章的基础上，Flow3r 运行着 MicroPython。MicroPython 使得任何人都能通过 USB 串口轻松连接到设备，并开始对输入和输出进行调试和操作。我在现场看到有人写了他们的第一个程序，并让徽章上的 LED 开始播放。

这些徽章总是激发出许多酷炫的创意，而这一次也不例外。欧洲的黑客营地已经开始共同努力，确保徽章在活动结束后不会成为电子垃圾。Badge.team 创建了一个相当稳定的接口，以便在 MicroPython 中编写的软件能够在徽章之间轻松移动，并且有一个应用商店可以方便地安装他人制作的应用程序。在默认固件中，有一个显示名字的应用程序，夜晚你可以看到数百人戴着徽章走来走去，显示着他们的名字。此外，你还会看到其他一些非默认的显示名字的应用程序，这是那些写了自己的显示名字应用程序或者下载了他们认为很酷的应用程序的人。

我的第三次营地之旅

这是我第三次参加由 CCC 主办的户外营地活动。当活动每四年进行一次时，你会在结识的人群中产生一种奇怪的步调。不知何故，我们竟然能在短短的 5 天内建立坚固的友谊。随着这次是我第三次参与，我正在第三次与 2015 年在我第一次营地相识的人们见面。不知何故，我们已经认识彼此整整 15 天，但在 8 年的时间里，却建立了一种非常牢固的友谊。我结识了朋友的新伴侣，听说了他们的孩子，还有机会将老朋友介绍给我的妻子，因为这是她第一次体验德国的露天活动。

在筹备婚礼这繁忙的夏天之后，CCCamp 成为我稍微放松的机会。我尽力避免组织活动，但计划赶不上变化。通过 Fediverse 的一位朋友帮助我主持了来自 MNT Reform 项目（/）的 Lukas 的展示活动，展示了他所构建的开源 Arm64 笔记本电脑。这对许多人来说是第一次尝试这款笔记本，并预览了即将推出的 7 英寸口袋款（如果你的口袋够大的话）笔记本电脑。首批设备预计将于 2024 年初发货，但原型硬件非常出色，可以用来调试各种问题。

由于无法抑制我“那个苏格兰人”的声望逐渐增长，我最终成为了一场威士忌品酒活动的主持人。但正如我所了解的，我会抓住任何机会向人群传递苏格兰诗歌。这一次，我朗读了彭斯的一小段，站在台上，大约有一千人热切地举着手等着我读这位诗人的几行诗。

"为了歌唱你的名字！"

到达某地

在旅行报告中，我经常会反复强调活动的价值难以事后向他人言语。我可以夸赞所发生的事情，但我不确定在路边的快闪展台上填写奥地利投诉表格的体验是否真正得以传达。他们的填写系统确实给人一种很像碎纸机的感觉。

对我来说，CCCamp 2023 的主角是酷热。德国经历了一场酷热的夏季，老实说，如果在我写这篇文章之前问我有关这个活动的看法，那可能就是我唯一会谈论的话题。当然，我的遮光帐篷帮助我多睡了一会儿，而躲在一个人工通风的阴凉处则帮助我坐下来为徽章写一个无聊的应用程序。

这场酷热创造了一些我没有经历过的新体验。

第四天，为了避免被烤熟，我独自一人在湖中游泳时，碰巧遇到了一艘充气艇，上面坐着一些 EMFCamp 的人。他们邀请我上船，我设法（只是稍微让他们的船漏了一点水），我们在湖上荡来荡去，一边分享着罐装的杜松子酒和汤力水（一种饮料，译者注）。

这种经历我想一定只有参加我们的活动才会感受得到。

TOM JONES 是一个关注保持网络堆栈敏捷性的 FreeBSD 提交者。

2023-0708 容器与云

我们收到的来信

原地址：
作者：MICHAEL W LUCAS
译者：ykla & ChatGPT

亲爱的 Crankypants，

2023-0506 FreeBSD 三十周年纪念特刊

AArch64：成为 FreeBSD 新的一级架构

原文：
作者：ED MASTE
译者：ykla【】为译者注

FreeBSD 起源于 386BSD，而且在最初仅支持一种 CPU 架构，即英特尔 80386。对第二种架构 DEC Alpha【是由迪吉多公司开发的 64 位 RISC 指令集架构微处理器】的支持在 FreeBSD 3.2 中被加入的，接着是对 64 位 x86（amd64）的支持。支持等级的概念尚未完全确定，但 amd64 在 2003 年被提升为一级支持状态。64 位的 ARM 架构 AArch64（也称为 arm64）在 2021 年获得了一级支持的地位。我们将探讨这意味着什么，以及我们是如何实现这一步的。

在 FreeBSD 中引入新的一级支持架构是份具有挑战性的任务，它需要大量的努力，以确保该架构得到充分支持、稳定、高性能，并且与现有的 FreeBSD 生态系统兼容。

字符设备驱动程序教程（第二部分）

原文链接：Character Device Driver Tutorial (Part 2)
作者：John Baldwin

在这篇三部分系列的上一篇文章中，我们构建了一个简单的字符设备驱动程序，该程序支持由固定缓冲区支持的 I/O 操作。在本文中，我们将扩展此驱动程序，以支持 FIFO 数据缓冲区，并支持非阻塞 I/O 和事件报告。每个版本的驱动程序的完整源代码可以在https://github.com/bsdjhb/cdev_tutorial找到。

然而，在继续之前，我们必须处理上一篇文章中未完成的部分。细心的读者 Virus-V 指出，文章中的 echo 驱动程序的最终版本没有在卸载时销毁 /dev/echo 设备，并且在卸载后访问该设备会触发内核 panic。这个 bug 的第一个线索出现在内核在卸载模块时发出的关于内存泄漏的警告消息，panic 发生之前就已经出现了这个警告。如前文所述，这是内核模块在可能的情况下应该使用专用 malloc 类型的原因之一。该 bug 出现在最后一组更改中添加的 echodev_create() 函数中。我们未能通过将值存储在 *scp 中将指向新分配的 softc 结构的指针返回给调用者。因此，echo_softc 变量始终为 NULL，softc 在模块卸载时未被销毁。修复方法是在 echodev_create() 中添加一行代码，在成功时将指针存储到 *scp 中，指向新的 softc。

使用 FIFO 数据缓冲区

上一篇文章中的 echo 驱动程序使用了一个平面的数据缓冲区进行 I/O 操作。读取和写入可以访问数据缓冲区的任何区域，并且数据缓冲区的整个范围始终有效。这些语义类似于访问一个在写入末尾时不会增长的文件。然而，字符设备驱动程序可以实现一系列不同的语义。对于本文，我们将修改 echo 驱动程序，使其像或这样的 FIFO 流设备一样对待用户 I/O 数据。I/O 写请求将数据追加到逻辑数据缓冲区的尾部，读取请求将从数据缓冲区的头部读取数据。像这样的文件偏移量将被忽略。驱动程序将继续使用内核中的缓冲区来保存用户数据的临时副本。写入将数据存储在此缓冲区中，读取将从此缓冲区中消耗数据。这意味着驱动程序现在需要跟踪缓冲区中有效数据的数量以及缓冲区的长度。为了简化实现，数据缓冲区的开始部分将始终被视为缓冲区的头部。读取请求如果读取了部分可用数据，将把剩余数据复制到缓冲区的前面。

然而，这确实提出了几个额外的问题。首先，如何处理希望从缓冲区中读取超过可用数据量的读取请求？其次，如何处理希望存储比缓冲区能容纳的更多数据的写入请求？为了简单起见，我们将首先对读取请求返回可用字节的短读取，并将写请求截断，只存储缓冲区中有足够空间的数据量。第三，对于一个 ECHODEV_SBUFSIZE 请求，如果将缓冲区缩小到小于有效数据量的大小，应该如何处理？我们选择使此类请求失败并返回错误。也可以选择丢弃一些数据，但必须决定丢弃哪些数据。列表 1 提供了更新后的读写方法。注意，softc 中新增了一个 valid 成员，用于跟踪缓冲区中有效数据的数量。示例 1 展示了这个更新后的驱动程序的一些场景。最初，设备为空，但待提供输入，就可以读取数据。最后几个命令跨两个请求读取了一系列字节。

列表 1：使用 FIFO 数据缓冲区的读取和写入

示例 1：简单的 FIFO I/O

阻塞 I/O

虽然这个版本的回显驱动实现了一个简单的数据流，但它也有一些局限性。如果一个进程想要使用这个设备共享一个比数据缓冲区大的数据块，它必须等到读者消耗完之前缓冲区中的数据，才能写入额外的缓冲区数据。这要求写入进程要么与读取进程协调，要么使用定时器并定期重试写操作。两种解决方案都不太实际。相反，驱动程序可以通过在缓冲区满时在写请求中睡眠，直到请求完成，从而允许更大的写入。读者在空间可用时会唤醒等待的写入者，从而允许写入者继续进行写入。类似地，读者可以阻塞等待数据返回。为了更贴近管道和套接字的语义，我们选择使读取请求仅在请求开始时阻塞，并在数据可用时尽快返回短读取。然而，对于写入操作，我们尝试一次性清空整个缓冲区。为了处理阻塞，我们使用了函数，它在将当前线程置于休眠状态的同时，原子地释放设备的锁。将 PCATCH 传递给该函数允许信号中断休眠，若中断发生，sx_sleep() 将返回一个非零的错误值。列表 2 显示了更新后的读取方法。写入方法也进行了类似的更新，但增加了一个额外的循环，直到写入完全完成。请注意，在写入方法中，如果写入操作部分完成，我们不需要“隐藏”错误。dofilewrite() 函数中的通用写系统调用处理将 sx_sleep() 的错误映射为成功，只要至少有一些数据被写入。一些 ioctl 处理程序也需要更新，以便在缓冲区增大或清空内容时唤醒正在休眠的写入者。

在测试这个版本的驱动时，示例 2 显示了一些可能令人惊讶的行为。尽管先前写入的数据会被返回，但会继续等待更多数据，直到被信号终止。

列表 2：阻塞读取方法

示例 2：阻塞 I/O 永久挂起

安全卸载

我们稍后会讨论示例 2 中的令人惊讶的行为。当前的驱动程序还有另一个问题。当一个进程在读取或写入方法中被阻塞时，卸载驱动程序会导致卸载模块的进程挂起，直到第一个进程被信号杀死。这不是管理员卸载模块时所期望的行为。相反，回显驱动程序应该在设备销毁时唤醒任何休眠的线程，并确保它们能够从驱动程序方法中返回，而不会再次进入休眠状态。为了支持这一点，下一个修改添加了一个 dying 标志到 softc 中，并且如果该标志被设置，读取和写入方法将返回 ENXIO 错误，而不是阻塞。在设备销毁期间，dying 标志被设置，并且在调用 destroy_dev() 之前，所有休眠的线程都会被唤醒。列表 3 显示了读取方法中的更改行和更新的 echodev_destroy() 函数。

列表 3：卸载时唤醒线程

读取时的条件阻塞

在示例 2 中，令人惊讶的是，在读取了设备上的可用数据后，cat(1) 仍然继续阻塞。然而，这种行为确实是我们驱动程序的自然结果，因为 cat(1) 只是循环调用，直到收到 EOF，而第二次调用 read(2) 会阻塞，等待更多数据。其他流设备（如管道和 FIFO）的语义是，如果没有进程打开设备进行写入，读取将返回 EOF 而不是阻塞。如果有设备被打开进行写入，则读取将阻塞，等待更多数据。

我们可以很容易地在回显驱动程序中实现这些语义。我们向 softc 中添加一个写入者计数器，只有当计数器非零时，读取方法才会阻塞。为了检测写入者，我们添加了一个打开方法，当每个请求写权限的打开操作时增加计数。可以通过检查传递给打开方法的文件标志中的 FWRITE 标志来确定这一点。一个新的关闭方法在写入者关闭时减少计数。默认情况下，关闭字符设备开关方法仅在没有剩余文件描述符时为设备的最后一次关闭调用。相反，我们设置了 D_TRACKCLOSE 字符设备开关标志，这样每次文件描述符关闭时都会调用关闭方法。如果最后一个写入者关闭，关闭方法会唤醒任何正在等待的读取者。列表 4 显示了新的打开和关闭方法，以及读取方法中的更改行。重试示例 2 中的步骤后，cat(1) 现在在读取完可用数据后会退出，不再出现令人惊讶的行为。

列表 4：跟踪打开的写入者

非阻塞 I/O

现在我们的回显设备支持阻塞 I/O。然而，一些消费者可能希望使用非阻塞 I/O。进程可以通过将 O_NONBLOCK 标志传递给，或者通过切换已打开文件描述符的 O_NONBLOCK 标志来请求非阻塞 I/O。字符设备驱动程序可以通过检查传递给读取和写入方法的文件标志中是否存在 O_NONBLOCK 标志来检查是否启用了非阻塞 I/O。如果请求了非阻塞 I/O，则应返回错误 EWOULDBLOCK，而不是在驱动程序会阻塞时阻塞。对于回显设备，这意味着在读取和写入方法中添加额外的检查，以确保在阻塞之前处理非阻塞 I/O。这本身足以处理在打开时请求的非阻塞 I/O。然而，为了支持通过 fcntl(2) 切换标志，还需要额外的步骤。

每次尝试通过 fcntl(2) 的 F_SETFL 操作设置文件标志时，都会在字符设备上调用两个 I/O 控制命令：FIONBIO 和 FIOASYNC。即使请求没有更改关联的 O_NONBLOCK 和 O_ASYNC 标志的状态，也会调用这些 I/O 控制命令。如果任何一个 I/O 控制命令失败，整个 F_SETFL 操作将失败，文件标志保持不变。因此，想要支持 F_SETFL 的字符设备驱动程序必须实现对这两个 I/O 控制命令的支持。

FIONBIO 和 FIOASYNC 将一个 int 值作为命令参数。如果新文件标志中清除了关联的文件标志，则该 int 值为零；如果新文件标志中设置了关联的标志，则该 int 值为非零。I/O 控制处理程序应该在请求的标志设置被支持时返回零，或者在请求的设置不被支持时返回错误。回显设备支持设置 O_NONBLOCK 标志，但不支持设置 O_ASYNC 标志，因此，如果 int 参数非零，回显设备的 FIOASYNC 处理程序会失败。

列表 5 显示了支持非阻塞 I/O 的读取和 I/O 控制方法的相关更改。

列表 5：支持非阻塞 I/O

投票 I/O 状态

使用非阻塞 I/O 的应用程序通常使用事件循环来处理多个文件描述符的请求。每次循环迭代，应用程序会阻塞，等待一个或多个文件描述符准备好（例如，数据可供读取，或有空间写入更多数据）。然后，应用程序会处理每个已准备好的文件描述符，之后再次等待。FreeBSD 为此类事件循环支持两个系统调用：和。在内核中，select(2) 和 poll(2) 是使用一个公共框架实现的。每个请求的文件描述符都被单独轮询，以确定它是否准备好。如果没有文件描述符准备好，则调用系统调用的线程可以睡眠，直到至少一个文件描述符变为可用。如果文件描述符在一个线程等待时变得可用，则该文件描述符必须唤醒正在休眠的线程。

函数族管理线程的休眠和唤醒。支持轮询的文件描述符必须为它支持的事件类型创建一个 struct selinfo 对象。该对象应通过将整个对象清零来初始化（例如，使用 memset()）。如果文件描述符的轮询函数发现文件描述符没有准备好，它必须对每个请求的事件调用 selrecord()，并将关联的 struct selinfo 对象传递给它。每当发生一个事件可能使文件描述符准备好时，必须调用 selwakeup() 在该事件的 struct selinfo 对象上。最后，在销毁 struct selinfo 对象之前，应该使用 seldrain() 唤醒任何剩余的线程。

对于字符设备，文件描述符轮询函数调用字符设备的轮询方法。此方法接受一个 poll(2) 事件的位掩码作为函数参数，并必须返回当前为真的事件掩码。此外，如果没有请求的事件为真，该函数还负责调用 selrecord()。请注意，字符设备不支持通过读写方法提供不同类型的优先数据，仅支持正常数据。

对于回显设备，我们支持读和写事件。我们在 softc 中添加了两个 struct selinfo 对象，每个事件一个。由于整个 softc 在创建时已被清零，因此在初始化 softc 时不需要进一步的更改。每个读写方法都会调用 selwakeup() 来唤醒可能等待的线程，针对的是 另一个 事件。其他一些地方也可以使回显设备变为准备状态，需要调用 selwakeup()。如果某个 I/O 控制命令扩展了缓冲区或清除了其内容，则可能会使设备准备好进行写操作。如果最后一个写入者关闭了设备，也可以使设备准备好进行读取。一个新的轮询方法确定设备的当前状态，并根据需要调用 selrecord()。最后，在销毁设备时，每个事件都会调用 seldrain()。列表 6 显示了在读取方法中对 selwakeup() 的添加调用以及新的轮询方法。请注意，对于读取方法，selwakeup() 用于写事件。

列表 7：设备轮询

一对通用的 I/O 控制命令对于检查文件描述符的状态也很有用。FIONREAD 和 FIONWRITE 分别返回可以在不阻塞的情况下读取或写入的字节数。字节数作为类型为 int 的控制命令参数返回。列表 8 显示了回显设备对这些 I/O 控制命令的支持。请注意，返回的值被限制为 INT_MAX 以避免溢出。

列表 8：FIONREAD 和 FIONWRITE

为了使这个功能更容易演示，我们在 echoctl 工具中添加了一个新的轮询命令。这个命令使用 poll(2) 查询回显设备的当前状态。如果设备可读，它会使用 FIONREAD I/O 控制命令输出可读取的字节数。如果设备可写，它会使用 FIONWRITE 输出可以写入的字节数。示例 3 显示了这个命令的几次调用，以及其他对回显设备的操作。请注意，由于在这个示例中没有其他写入者，设备即使为空也仍然是可读的。

示例 3：轮询 I/O 状态

通过 kqueue(2) 报告 I/O 状态

FreeBSD 提供了内核事件通知机制，这是一个与 select(2) 和 poll(2) 独立的 API。通过 kqueue(2)，应用程序为每个所需事件在内核中注册一个持久性的通知。内核生成一系列事件，应用程序可以消费并采取相应的行动。与 select(2) 和 poll(2) 不同，应用程序无需每次等待新事件时都注册它关心的所有事件。这减少了应用程序的开销，同时也允许内核更高效地跟踪所需的事件。

一个内核事件由一个过滤器（事件类型）和标识符组成。某些事件的行为可以通过不同的标志进一步定制。对于文件描述符的 I/O，两个主要的过滤器是 EVFILT_READ 和 EVFILT_WRITE，分别用于判断文件描述符是否可读或可写。这些事件过滤器的标识符字段是整数文件描述符。此外，对于读写事件，内核事件结构还返回可以读取或写入的数据量，作为一个单独的字段。这避免了单独调用 FIONREAD 和 FIONWRITE I/O 控制命令的需要。

在内核中，内核事件由 struct knote 对象描述。此结构包含用于生成返回给应用程序的事件的事件字段副本。活动事件的列表存储在 struct knlist 对象中。由于 select(2) 和 poll(2) 处理的 I/O 事件通常与内核事件关联，因此 struct selinfo 将 struct knlist 作为其 si_note 成员嵌入其中。每个 knote 还与指向 struct filterops 对象的 kn_fop 成员相关联。这个结构以及用于操作 knote 和 knote 列表的 API 在中有描述。

对于字符设备，kqfilter 方法负责将 struct filterops 对象附加到 knote 上。这包括设置 kn_fop 成员并将 knote 添加到正确的 knote 列表中。因此，字符设备的 struct filterops 对象不使用 f_attach 成员。struct knote 的 kn_hook 成员是一个不透明指针，kqfilter 方法可以设置该指针来将状态传递给 struct filterops 方法，类似于 struct cdev 中的 si_drv1 字段。

对于回显驱动程序，我们定义了两个 struct filterops 对象：一个用于读事件，另一个用于写事件。每个事件包括 f_detach 和 f_event 方法。我们重用了现有的读写 struct selinfo 对象中嵌入的 knote 列表。由于回显驱动程序使用了 sx(9) 锁，我们定义了自定义的锁回调函数，在创建回显设备时与 knlist_init() 一起使用。f_detach 方法使用 knlist_remove() 从关联的 knote 列表中移除 knote。f_event 方法将 kn_data 字段设置为适当的字节数，并在字节数非零时标记事件为已就绪。对于读事件的 f_event 方法，如果没有写入者，它还会设置 EV_EOF。新的 kqfilter 字符设备方法将 knote 附加到 EVFILT_READ

列表 9：EVFILT_READ 过滤器

列表 10：kqfilter 设备方法

与 poll(2) 支持一样，我们通过向 echoctl 工具添加另一个命令来演示 kevent(2) 支持。新的 events 命令为 echo 设备注册读取和写入事件，并在接收到每个事件时输出一行。由于读取和写入事件默认是按级别触发的，echoctl 在为 echo 设备注册事件时设置了 EV_CLEAR 标志。这样，仅在设备状态变化时才报告事件，触发驱动程序内的 KNOTE_LOCKED() 调用。示例 4 显示了跨一系列操作的 events 命令输出。前两个事件报告的是 echo 设备处于空闲状态时的初始状态，此时没有打开的读取器或写入器。在另一个 shell 中，我们执行命令 jot -c -s "" 80 48 > /dev/echo 向 echo 设备写入 81 字节数据。由于默认缓冲区大小为 64 字节，此命令在写入 64 字节后会在 write(2) 系统调用中阻塞。64 字节的写入触发了下一个 EVFILT_READ 事件，报告 64 字节可供读取。最后，在第三个 shell 中，我们执行命令 "cat /dev/echo" 从 echo 设备读取所有数据。cat(1) 的第一次 read(2) 系统调用读取了 64 字节输出，并触发了一个 EVFILT_WRITE 事件。然而，在 echoctl 进程查询 echo 设备状态之前，jot(1)

示例 4：通过内核事件报告 I/O 状态

结论

在本文中，我们扩展了 echo 设备，以支持具有阻塞和非阻塞 I/O 的 FIFO 数据缓冲区。我们还添加了通过 poll(2) 和 kevent(2) 查询设备状态的功能。本系列的最后一篇文章将描述字符设备如何为通过创建的内存映射提供后备存储。

John Baldwin 是一名系统软件开发人员。他在过去二十多年中，直接向 FreeBSD 操作系统提交了多项更改，涵盖了内核的各个部分（包括 x86 平台支持、SMP、各种设备驱动程序和虚拟内存子系统）以及用户空间程序。除了编写代码外，John 还曾在 FreeBSD 核心团队和发布工程团队任职。他还为 GDB 调试器做出了贡献。John 与妻子 Kimberly 和三个孩子 Janelle、Evan 和 Bella 一起居住在弗吉尼亚州的阿什兰。

使安装程序易于使用

Installer Usability
作者：Pierre Pronchery

亲爱的读者：

在撰写本文时，我完全不知道你是谁。这可能是你首次接触有关 FreeBSD 的文章；你也可能已经对系统非常熟悉了——毕竟你可能亲自编写了其中一半的代码。我也不清楚你正在使用何种硬件来阅读这篇文章；它甚至可能尚未问世，也不知你是否有任何残障或不便。

这正是操作系统安装程序所要应对的挑战。它必须在各种情况下都能正常工作，同时对所有人都要具有吸引力和可用性，甚至需要预见未来的演进。这是一项艰巨的任务。

安装程序往往是潜在用户与系统第一次交互的入口，因此它负责形成第一印象。与此同时，专业用户在个人硬件上不太需要频繁使用安装程序——基本上只在设置新系统时用到——但他们可能需要自动化安装多台系统来执行各种任务，或者在专业场景下为客户部署。

综上所述，这些不同方面可以从一个角度来看：可用性。但什么是可用？更重要的是，与其他系统相比，FreeBSD 安装程序的可用性又如何？

现状

Microsoft Windows 的演进

安装程序历史悠久。我的初次接触要追溯到 1989 年，家里引入计算机的时候。那时通常先安装 MS‑DOS，然后在其上安装 Windows 3.1。显然，安装 MS‑DOS 是在文本模式（80 列 VGA）下进行的，但可以禁用颜色——这也起到了一种粗糙的无障碍功能：高对比度。

虽然安装过程在文本模式下进行，但进度条和针对用户输入的高亮已经问世。

另一方面，Windows 安装程序（此处为 3.11 版）很快使用了自身的图形界面进行安装，如下所示。

值得一提的是，我在 VirtualBox 中，基于 archive.org 上的公共领域材料，自己制作了这些截图¹²³。

接下来是 Windows 95。和 Windows 3.11 一样，它在安装程序中使用了自身的用户界面，不过有两个中间步骤。通过以下截图可以看出，安装过程相对无痛，但需要用户交互的步骤明显增多⁴。

将 Windows 98 纳入讨论值得一提，因为它带来了一些改进：安装步骤总览列表和剩余时间估算⁵。

我就不再展示其他版本的 Windows 安装过程了。只要加上 Windows 7，就能总结出以下有关安装程序可用性的模式⁶：

我们可以无休止地争论 FreeBSD 是否真正与 Microsoft Windows 竞争。从 FreeBSD 项目的官方网站来看，它确实有瞄准桌面系统的雄心，如今已有 Laptop Desktop Working Group（LDWG，笔记本桌面工作组）为证。不过，无论这场争论的结果如何，我认为我们都能从消费级市场中获益，哪怕只是作为参考。以下是在实际体验中浮现出的若干模式和标准：

评估标准

MS‑DOS 6.22

Windows 3.11

Windows 95

Windows 98

Windows 7

如果要总结这套安装器的优势，我会指出以下几点：

通常会提供整体进度的指示。
即便时间预估可能不够精准，它对终端用户来说依然具有参考价值。
仅保留最关键的决策项由用户选择（如目标磁盘和安装目录），而将技术性决策默认隐藏：
- 文件系统的选择，

尽管在 Windows 7 发布之后又发布了三个主要版本，但在可用性层面上，我并未观察到显著的变化。

FreeBSD 的现状

截至撰写本文时，FreeBSD 的最新稳定版本是 14.2。注 7、8

如果单从可用性（usability）的角度来看，FreeBSD 的安装器显得有些落伍了，尤其是在体验了 Windows 7 之后，这一点更加明显。

评估标准

FreeBSD 14.2

不过，这样的比较并不完全公平：Microsoft Windows 明确面向非技术用户，追求“一套通吃”的图形化安装体验，并提供了完善的客户支持体系，而 FreeBSD 更偏向资深用户和系统管理员。

那么，如果将它与更接近的竞品做比较，会是什么样的结果？

Linux：Ubuntu Server（服务器版）

Ubuntu 会根据用途提供不同的安装镜像。为了保持对比的公平性，本文使用的是 Ubuntu Server 24.04.02 LTS。注 9

乍一看，这套安装器和 FreeBSD 十分相似：整个安装过程都保持在纯文本界面（text mode）中，首启后也是登录到命令行。这种形式更符合 FreeBSD 用户的预期。不过，实际操作中 Ubuntu 的安装流程显得更加简单直接。

评估标准

Ubuntu Server 24.04

相较于 FreeBSD 的明显优势

安装器支持多种语言选择。
安装问题集中一次性提问，实际安装过程一气呵成。
安装期间可以选择预定义用途（如通过 Snaps 安装服务组件）。

这些细节虽然小，却对用户体验有明显的正向影响。如果 FreeBSD 安装器希望跟上当今的趋势，这些正是可以借鉴的改进方向。

Linux Ubuntu（桌面版）

接下来，我尝试了 Ubuntu Desktop，版本同样是 24.04.02 LTS。

正如预期，这个版本提供了图形化的用户体验。但更重要的是，在我个人的感受中，其整体的质量与打磨程度处于另一个层次。

评估标准

Ubuntu（桌面版）

在可用性方面，这无疑是一个参考标准。至于 Microsoft Windows，这种表现可以说是商业支持下的解决方案应有的水平。但为了更公平地比较 FreeBSD，我们应将其与另一个社区项目进行对比。因此，在深入探讨 FreeBSD 自身的安装程序之前，不妨先看看 Ubuntu 的母项目、非商业发行版：Debian。

Debian GNU/Linux

译者注：Debian 亦有高级安装模式（Expert Mode），原作者测评的是普通安装模式。在高级安装模式下可对每个选项进行精确规划。

与 Ubuntu 不同，这个比较是一个“二合一”：Debian 的 netinstall 安装器体积仅有 632 MB，却同时包含了文本模式和图形化模式两种形式。

顺带一提：在我主要转向 BSD 系统之前，我长期使用的类 UNIX 发行版就是 Debian。在惊喜地发现其混合式安装方式之后，我再次遇到了令人沮丧的熟悉体验：安装过程提出一连串看似无止境的问题，而且每一组问题之间还伴随着耗时的处理过程。

评估标准

Debian GNU/Linux

尽管提供了图形模式，但其视觉外观相当粗糙。我也感到惊讶，除了启动菜单中的高对比度模式外，并未发现其他辅助功能；当然，也有可能是我漏看了。

不过，从非常积极的方面来说，要获得一个适用于服务器或桌面用途的安装环境是非常容易的。这一点与其安装器的混合设计非常契合。

那么，FreeBSD 能否也达成类似的成果？

特别提及：macOS

最后但同样重要的一点，我想提及 macOS。虽然 macOS 最初也基于 BSD 系统，但 macOS 能够依赖一套众所周知的自家硬件设备数据库。系统固件内置了多种备用机制，用于以不同方式（重新）安装系统——包括无需任何安装介质：整个系统可以由固件直接从互联网下载并恢复。

这一点令人印象深刻，堪比前文提到的商业解决方案；但同样，这样的比较对我们心爱的 FreeBSD 并不公平。不过，我仍想强调一点：系统中应当至少提供足够的基本工具，以便进行分析和修复操作；这在意外情况下可能就是救命稻草。

深入探讨 FreeBSD

根据我自己阅读其源码的经验，目前 FreeBSD 安装器的状况，直接源自一些架构层面的设计决策。我想强调的是，这并非对其实现方式或当时决策的全盘否定；重点在于理解我们如今所处的位置：这个安装器是否已到重写的时机，或者是否还有一些战役可以通过简单的手段去赢得？

架构

大多数 FreeBSD 安装器由 shell 脚本组成，其中部分步骤通过专门的 C 程序实现。可在 src.git 仓库中找到其完整源码，但其底层架构实际上由三大组件构成：

bsdconfig：位于 usr.sbin/bsdconfig，作为一套 shell 例程库被 bsdinstall 调用使用。
bsddialog：位于 usr.bin/bsddialog，是与用户交互的工具，负责收集输入和显示进度。
最后是 bsdinstall 本身，位于 usr.sbin/bsdinstall。

当启动 FreeBSD 安装镜像时，有专门的 rc.local 启动脚本（来自 release/rc.local）在启动过程结束时运行 startbsdinstall。这个脚本提供欢迎界面，并允许将安装介质作为 Live 系统使用。在默认情况下，Live 模式只是启动一个 shell，这对有经验的 UNIX 用户来说是熟悉的环境，但对一般用户而言，并不算是真正意义上的 Live 或修复系统。

聚焦安装过程，其整体流程如下：

启动 startbsdinstall（如上所述）。
bsdinstall 可直接调用特定操作，其子命令位于 /usr/libexec/bsdinstall，默认使用 auto（本次选择）。
auto 会依次执行以下操作：

正面的第一点是，即便安装介质中缺少部分系统组件，安装流程也能妥善处理。这允许创建不同大小的安装介质，而无需改动安装逻辑。

但另一方面，这一过程对用户提问过多。虽然每一个问题单独来看都显得重要而有用，但前文描述的其他系统，仅需三分之一的交互步骤就能构建出完整可用的系统。不幸的是，用户界面的问题还不仅限于此。

限制与使用场景

对 bsddialog(1)（或 C 程序中使用的 libbsddialog）的高度耦合，引入了与 Debian 安装器类似的限制：每一步的用户界面都相当基础，且无法根据用户输入动态调整交互。例如，网络配置步骤不能依据常见习惯自动建议合适的网络掩码、DNS 服务器或网关。这不仅会节省用户一些按键输入和不必要的精力，还会让整体体验显得更现代、更精致。

可能的解决方案：Lua

这个具体问题可以通过在 libbsddialog（或 bsddialog(1)）中引入 Lua 脚本支持来解决。这个想法由 bsddialog 的作者 Alfonso Siciliano（asiciliano@）提出，他目前正考虑将该扩展实现到项目中。

初学者用户

对于初学者，或者说一般桌面用户来说，显而易见的改进方向是：能够方便地安装一个在首次重启后就可直接使用的桌面系统。虽然这意味着需要增加一个安装步骤，但可以借鉴上文提到的 Debian 安装器，为服务器和桌面系统都提供适配的选项。

目前在这个方向已有实验性工作（专门由 Alfonso 牵头），但“写起来容易，实现起来吃力”。其中一些挑战包括对应固件文件和驱动程序的安装，尤其是内核模块 DRM 一直是个难点。当前已有一项尝试（致谢 manu@）试图将这些模块从 Ports 移回基本系统中，这应该能缓解当前二进制 Ports 中常见的版本不匹配问题。

企业用途

这次要说点积极的方面：FreeBSD 的安装器可以调整并自动化，以适应企业部署中的典型需求。

首先，它默认就支持设置 jail，而不是执行常规安装。这种行为可以通过选择 jail 模式（而不是默认的 auto）来实现。操作如下所示：

如果未来要对 FreeBSD 安装器进行重构或大幅修改，保留这一功能将是值得考虑的。另一方面，目前已有许多 jail 管理方案存在于 bsdinstall(8) 之外。

更重要的是，安装器还支持 script 模式，此时需要提供一个安装脚本，在 bsdinstall 上下文中执行。这种方式由系统管理员编写脚本，从而实现完全自动化的 FreeBSD 安装过程。

在本节结尾，我必须提及一个至今仍缺失的功能，而其他对比对象都已具备这一能力：安装器默认假设无需代理服务器即可访问互联网。这个问题记录在 Bugzilla 的条目 #214390 中。根据我自己的经验，在为数十家客户提供渗透测试部署的场景中，这种限制往往直接导致 FreeBSD 安装器无法采用。

开发环境

公平地说，开发 bsdinstall(8) 并不容易。测试某些修改通常需要构建一个完整的可启动镜像，在虚拟环境中运行它，并重复整个安装流程，直到抵达需要测试的那一特定步骤。为了提高开发安装器时的效率，我尝试构建了一个专门适配此目标的开发环境。

它由一个基于 PXE 的设置组成，可针对传统的 PXE 环境以及更现代的、基于 UEFI 的网络引导进行调整。我将此引导序列与一台 TFTP 服务器（由 inetd 管理）、DHCP 服务（使用 isc-dhcp44-server 软件包）以及只读的 NFS 挂载结合在一起。完整描述该设置超出了本文的范围，但归根结底，FreeBSD 安装器的可用性也取决于其开发环境的便利性。你可以根据自己的需求自由调整以下配置片段。

对于 /etc/exports：

对于 /etc/inetd.conf：

对于 /etc/rc.conf：

对于 /usr/local/etc/dhcpd.conf：

请将 loader.efi 和 pxeboot 文件放置于 /tftpboot/FreeBSD/boot 目录中。

你可以将 /jail/bsdinstall 文件夹设置为一个典型的 jail，并根据安装器的常规启动环境进行调整，或者也可以直接暴露 release 构建中的 disc1 目录。无论哪种方式，这种方法都能避免在开发 bsdinstall 时频繁地生成、传输或重启镜像文件。

需要注意的是，这一设置在物理硬件和虚拟机中都同样适用，因为 VirtualBox 等虚拟化平台支持从 PXE 引导。

图形模式

最后，是时候回答这个问题了：我们能否改进 FreeBSD 安装器，使其功能达到例如 Debian 安装器的同等水平？

背景

2024 年初，FreeBSD 基金会委托我调研开源领域中图形化安装器的最新进展。其根本目标是为 FreeBSD 项目寻找一种可行方案来增加图形安装功能。Linux 上一个新的安装框架 Calamares12 是显而易见的候选者——前提是确认它可以用于 FreeBSD 作为目标系统。不幸的是，由于 Calamares 使用 GPL 许可证，与 FreeBSD 基本系统的目标用户群不兼容。

另一个当时关注度较高、且特定于 FreeBSD 的替代方案是 PC-BSD。它经过首次品牌更名为 TrueOS 后，于 2020 年停止维护。随后建议的替代品包括 GhostBSD、MidnightBSD 和 NomadBSD。

GhostBSD 提供了图形安装器 gbi。虽然是个不错的候选，但它与当前 bsdinstall 代码库差异较大，同时还需要完整的 Python 和 Gtk+ 环境。在我看来，更高效的方案是可行的。

据我所知，MidnightBSD 和 NomadBSD 均未提供图形安装器（译者注：NomadBSD 有图形安装器，这里原作者是错误的）。

最小侵入式方案

相反，鉴于我已熟悉 bsdinstall 和 bsddialog，我设想可以重用现有代码库与架构，同时用图形界面执行安装流程。通过用功能等效且同样采用 BSD 许可证的工具替换 bsddialog(1)，可以在项目分配的几周时间内交付一个功能完善的安装镜像。

我本人对 Gtk+ 也较为熟悉，考虑到仅需做一个可用的演示，这是一种合理的折衷。Gtk+ 采用 LGPL 许可证，仍然与目标用户群的许可兼容性不完全吻合。但我还是在几天内成功实现了 gbsddialog，它是 bsddialog 的桌面应用等效版本。

我对这个工具的最初设想略有不同，希望能做一些额外的改进或变通：

防止对话窗口在每次调用之间消失再重新出现，比如通过使用 GtkPlug 和 GtkSocket 小部件来实现。
在解决了上述问题后，使用 GtkAssistant 小部件来提升界面的美观和用户体验。
bsddialog 中有一个特定的小部件 mixedgauge，其实现方式不适合用于图形化版本的工具：在 bsdinstall 中，通过滥用 bsddialog 控制台输出的持续存在感来营造进度感，实际上每次更新时都会执行新的 bsddialog 实例。在图形安装器中，这种监控只能用普通的 gauge 小部件替代，牺牲了部分可用性。

另一方面，我对桌面窗口的实现感到相当满意，它相当准确地复刻了原始 bsddialog 工具的外观与交互体验。尽管这部分代码目前还不够优雅，但它确实完成了任务。

修复与升级功能

去年，我有幸与一位非常积极的学生 Leaf Yen（你好！）共同指导谷歌编程之夏项目。该项目旨在为 FreeBSD 安装器引入新功能：通过可移动介质升级或修复现有系统。

项目成功完成，并在 GitHub 上提交了三个合并请求：

#1395，GSoC 2024 —— 改进安装器以支持修复和升级。
#1424，bsdinstall：在 live 环境中添加 pkg 安装支持。
#1427，bsdinstall：向安装菜单添加修复脚本。

我尚未将这些工作集成到图形版本安装器中，但我认为它们是现代安装器同样重要的组成部分。也请把这篇文章看作是对该项目的关注呼吁——一旦完善并合并，应该能同样适配当前安装器和图形版本。

作为网页应用的图形安装器

如果不提这个潜在的额外加分项，文章就不完整了。自 Gtk+ 3 起，Gtk+ 应用可以直接在网页浏览器内渲染，而不是仅限于电脑屏幕，这得益于 GDK Broadway 后端。

虽然我还没尝试过这个功能，但这似乎意味着可以把图形安装器版本变成一个网页服务器，从而实现无任何额外改动的网络安装 FreeBSD 系统！这显然是另一个潜在的轻松突破点。

可访问性

我想特别提到采用 Gtk+ 作为图形安装器演示器的另一个标准：可访问性。

虽然我自己也有一些残障状况，但尚未严重到让我深入尝试 Gtk+ 的可访问性特性。不过我知道它在这方面的能力，也明白对于部分需要辅助功能的人群，操作系统安装器的可用性十分关键。事实上，我听说过无论是私下还是会议上，都有人提出安装器需要支持辅助功能。

目前还有一个资助项目，旨在为 FreeBSD 安装器引入辅助功能，由 Alfonso Siciliano 负责调研。（再次问候！）

回到 Gtk+，它支持以下可访问性需求：

屏幕阅读器，如 Orca，用于转换语音或盲文。
完整的键盘导航。
标准小部件的无障碍行为。
高对比度主题或其它视觉增强主题。

虽然我还没机会与有需求者一起实际体验这些功能，但我在开发 gbsddialog 期间始终牢记这一点，始终遵循核心 Gtk+ API。因此，该工具兼容 Gtk+ 2 和 Gtk+ 3。

在文章结尾前，我想提一下 DeforaOS 桌面环境。它是另一个轻量级桌面环境，大部分由一位个人开发（你好！），坦白说它的完成度和质量远未达到我追求的目标。它部分被打包到 FreeBSD 的 ports 中（感谢 Olivier！），我在此图形安装器演示中也使用了它——哪怕只是为了展示其能力。

不过，我很高兴提及它带有虚拟键盘程序，并且我成功将其与图形安装器版本配合使用。

基于本文所述的进展，我更新了 FreeBSD 功能对照表如下：

评估标准

FreeBSD 14.2

结论

这确实是一个容易引发分歧且颇具主观性的议题。我希望本文对 FreeBSD 安装流程的改进有所助益，推动未来版本的优化。不幸的是，基于现有代码库工作并非易事，每次测试都需生成和启动安装介质，极为耗时且考验耐心。简单的改动可能无意中影响硬件支持或整体用户体验质量。

显而易见，FreeBSD 安装器还有大量改进空间。在工作期间，我也听到过彻底重写的呼声。但这既不是一个容易做出的决定，也不是一个轻松实现的项目——尤其要兼顾各种使用场景、满足各方需求，同时控制在合理预算内。

坦白说，我并不觉得自己有资格判断或强加某种方案。我更希望能提供并维护一项简单的、现有安装器的渐进式演进方案，在不引入不必要变动的前提下，扩展其能力。正如本文所述，通过复用现有代码，对基于控制台的安装器所做的 bug 修复和改进同样会体现在图形版本中，反之亦然。

参考文献

Pierre Pronchery 是 FreeBSD 基金会的安全工程师，自 2023 年 5 月起担任用户空间软件开发者。他于 2001 年安装了第一套 FreeBSD 系统，对操作系统设计与实现充满热情。