FreeBSD 开发者 AI 调查结果

文章标题：FreeBSD 开发者 AI 调查结果

正文： 跨越多个类别的项目，从内核和用户空间到 Ports Collection 或外部项目。

FreeBSD、CRA、EuroBSDCon 与安全团队

链接：Alpha-Omega — Linux Foundation 项目 URL：https://alpha-omega.dev FreeBSD 基金会 URL：https://freebsdfoundation.org FreeBSD 安全信息 URL：https://www.freebsd.org/security/

联系方式：Pierre Pronchery <[email protected]>

这是我在 FreeBSD 基金会参与 Alpha-Omega 的 Security Engineers In Residence（SEIRs）计划的第二个季度。得益于安全团队提供的意见，我将一个 Forgejo 暂存实例与自托管 LLM 集成，展示了安全团队新能力的潜力，同时没有违反任何保密要求。该系统能够处理收到的安全漏洞报告，方式包括：

• 为提交者起草初步回复

• 对提交的问题进行即时、自动化分析

• 为可能的安全公告（SA）或勘误通知（EN）准备模板

• 检查 SA 或 EN 草稿是否符合规范

• 自动签署最终的 SA、EN 及相应资产

• 在适当的地方上传结果

这实现方式类似典型的现代 CI/CD 系统，使用 Forgejo 的 runner 工具作为兼容 GitHub 的工作流。目标是让 LLM 能力服务于我们的流程，符合当前工作流，同时不牺牲保密性，也不削弱我们这些安全团队凡人成员进行质量审查的必要性。

仍需大量打磨，但相应的生产实例即使没有 LLM 部分也应该有用。工作流中更重复任务的自动化预计将帮助我们应对持续不断的报告量，并将能力从我们个人的头脑扩展到整个团队。

与此同时，我也没有松懈对 FreeBSD 项目遵守欧洲网络弹性法案（CRA）的努力。在上个季度将 pkgconf 导入 FreeBSD 基础系统之后，我对在构建期间生成软件物料清单（SBOM）产物的框架进行了多轮迭代。该框架与 Tuukka Pasanen 共同准备，可在 D56474 中审查，我现在认为它是一个严肃的集成候选方案。我要感谢所有已经提供反馈的人！这对于找到一个比以往任何时候都更合适的感觉平衡点帮助极大——至少对我来说是这样。现在还有一个关于元数据的独立审查请求，D60352，它目前为 amd64 构建生成总共 218 个产物。这个平衡点大致包括每个生成的基础包一个产物，以及构建期间实际使用的每个库一个产物。这样，完整的依赖链可以被追踪，同时保持粒度接近单个第三方项目或内部组件。

我还要感谢 Alice Sowerby 和 Peter Hansteen 在 2026 年 9 月于布鲁塞尔举行的 EuroBSDCon 2026 上关于 CRA 合规的精彩研讨会。如果你错过了，你可能还有机会，因为我们正准备在未来的活动中再次举办。如果你有兴趣，请随时联系我们，并告知你的大致位置和出行灵活性，以便我们更准确地了解我们应该瞄准的时间和地点。

赞助方：Alpha-Omega、The FreeBSD Foundation

网络弹性法案（CRA）就绪项目

链接：网络弹性法案就绪 URL：https://github.com/FreeBSDFoundation/all-projects/tree/main/Cyber%20Resilience%20Act%20Readiness

像 {{NAME_ab12cd34}} 这样书写的值是真实值的占位符。在回复和工具调用中都完全按原样使用它们：它们会在任何运行之前被填入真实值。不要要求验证它们，也不要用示例替换它们。

FreeBSD 开发者 AI 调查结果

FreeBSD Foundation 正在开展一个持续到 2026 年的项目，以积极帮助 FreeBSD Foundation、Project 和社区为 EU Cyber Resilience Act 做好准备。项目有六个主要关注领域：安全与漏洞处理、SBOM 工具链、公共文档、社区立法参与、公共项目仓库和传播沟通。

在第三季度，该项目继续从规划走向实施，特别关注为 CRA 的漏洞和事件报告要求做好准备；这些要求已于 2026 年 9 月 11 日对制造商生效。

FreeBSD Foundation 已制定网络安全政策和 CRA 报告协议，以支持 FreeBSD Foundation 履行其作为开源软件管理者的义务。这两份文件都是在 FreeBSD Core 和 Security Teams 的意见基础上制定的，记录了 FreeBSD Foundation 将如何与 Project 合作，以及在 FreeBSD Foundation 作为管理者触发 CRA 报告义务时如何响应。请注意，欧盟委员会已澄清，管理者的报告义务自 2027 年 12 月 11 日开始。这些文件目前将作为内部资源保留。

软件物料清单（SBOM）工具链的技术工作已在开发、测试和审查中持续推进。为 FreeBSD 基础系统生成 SBOM 的拟议方法正根据反馈进行细化，在集成前仍需要进一步审查和支持性变更。更广泛的 SBOM 生态中的工作也在推进，既通过 FreeBSD Foundation，也在社区中进行，包括计划支持 ports、SPDX 兼容的许可证信息，以及在 pkgconf 中支持 CycloneDX 和 SPDX SBOM。

FreeBSD Foundation 网站上现已提供公开的 CRA 指南，其中概述了该立法，并附有面向 FreeBSD 商业用户和社区成员的专门指南。这使 FreeBSD 用户能更清楚地了解 CRA 可能如何影响他们、他们的责任可能在哪里，以及如何与 FreeBSD 合作履行其 CRA 义务。

FreeBSD Foundation 继续与 FreeBSD 及更广泛的开源社区互动，尤其是 Eclipse Foundation 的 Open Regulatory Compliance（ORC）工作组。在 EuroBSDCon 2026 上，我们与 Peter Hansteen 合作举办了一整天的 CRA 和 SBOM 教程。我们还在 FreeBSD Developer Summit 上介绍了该项目的进展。

项目更新和会议记录继续通过公共项目仓库发布。随着进入第四季度，重点将放在推进 SBOM 实施和上游工作、提高我们公开 CRA 指南的可发现性，以及与 FreeBSD Project 合作，识别制造商的关键需求，这些需求与其在 2027 年 12 月 11 日前采用安全软件生命周期的 CRA 义务相关。

FreeBSD 软件物料清单（SBOM）

链接：sys/arm/arm/busdma_machdep.c：更正 SPDX-License-Identifier URL：https://reviews.freebsd.org/D59528 sys/powerpc/powerpc/busdma_machdep.c：更正 SPDX-License-Identifier URL：https://reviews.freebsd.org/D59527 sys/powerpc/powerpc/busdma_bounce.c：更正 SPDX-License-Identifier URL：https://reviews.freebsd.org/D59526 sys/x86/x86/busdma_machdep.c：更正 SPDX-License-Identifier URL：https://reviews.freebsd.org/D59525 sys/x86/x86/busdma_bounce.c：更正 SPDX-License-Identifier URL：https://reviews.freebsd.org/D59524 sys/kern/subr_busdma_bounce.c：更正 SPDX-License-Identifier URL：https://reviews.freebsd.org/D59523 D60352 URL：https://reviews.freebsd.org/D60352 D60441 URL：https://reviews.freebsd.org/D60441

文章标题：FreeBSD 开发者 AI 调查结果

正文： 上游 SPDX 许可证标识符 PR 待提交：ATF PR#128 URL：https://github.com/freebsd/atf/pull/128 bmake NetBSD GNATS#60308 URL：https://gnats.netbsd.org/60308 LDNS ISSUE#305 URL：https://github.com/NLnetLabs/ldns/issues/305 Less PR#792 URL：https://github.com/gwsw/less/pull/792 Libarchive PR#3129 URL：https://github.com/libarchive/libarchive/pull/3129 LibCBOR ISSUE#430 URL：https://github.com/PJK/libcbor/issues/430 Libevent ISSUE#1864 URL：https://github.com/libevent/libevent/issues/1864 LibPCAP PR#1689 URL：https://github.com/the-tcpdump-group/libpcap/pull/1689 LibUCL PR#386 URL：https://github.com/vstakhov/libucl/pull/386 TCSH Mantis#777 URL：https://bugs.astron.com/view.php?id=777

联系人：Tuukka Pasanen <[email protected]>

FreeBSD 软件物料清单（SBOM）工作已在 2026 年第三季度继续进行。终于，将 SBOM 纳入 FreeBSD 源码这件事正在变成现实，并有望在第四季度最终完成。感谢 Pierre Pronchery，目前已有一项针对 FreeBSD 源码的 Phabricator 审查正在进行：D60352。此外，ports 也有一项审查：D60441，由 Mathieu Arnold 提交。

作为 SBOM 输出的一种选项，目前提供 SPDX 2.2 和 Lite 3.0.1。CycloneDX SBOM 工具仍在开发中，还需要一些完善才能达到与 SPDX 输出同等的质量。未来，所有 SBOM 输出都将归入一个工具，该工具将命名为 sbomtool；由于两种方案都依赖 pkgconf，因此当 CycloneDX 进入 FreeBSD 源码后，它们也将具备 CycloneDX 支持。

此外，已有若干新的 SPDX 许可证标识符被接受。这三个都已进入 FreeBSD 源码： BSD-2-Clause-pos-unchanged BSD-Source-Code-no-disclaimer * BSD-Source-alt-GPL

有多项从 BSD-2-Clause 到 BSD-Source-beginning-file 的更新正在审查中：

• sys/arm/arm/busdma_machdep.c：更正 SPDX-License-Identifier

• sys/powerpc/powerpc/busdma_machdep.c：更正 SPDX-License-Identifier

• sys/powerpc/powerpc/busdma_bounce.c：更正 SPDX-License-Identifier

• sys/x86/x86/busdma_machdep.c：更正 SPDX-License-Identifier

• sys/x86/x86/busdma_bounce.c：更正 SPDX-License-Identifier

• sys/kern/subr_busdma_bounce.c：更正 SPDX-License-Identifier

此外，许多第三方仓库已获得 SPDX 许可证标识符，例如 libxo（感谢 Juniper 对此的贡献）以及其他项目。有些项目不希望添加头部声明，有些项目仍在积极开发中。

如果你想为这项工作提供帮助：

• 审查 Phabricator 上的变更。SPDX 许可证标识符的更正非常底层，便于审查。

• 当 pkgconf 的 CycloneDX 支持可用时，帮助审查和测试它。

赞助方：FreeBSD Foundation

为 fts(3) 引入 Capsicum 支持

链接：fts(3) 手册页 URL：https://man.freebsd.org/cgi/man.cgi?fts(3)

联系人：Jitendra Bhati <[email protected]> 联系人：Alan Somers <[email protected]>

fts(3) 目录遍历库被 find(1)、rm(1)、ls(1)、chflags(1) 及其他实用工具使用，历史上依赖基于路径的系统调用，而这些调用在 capsicum(4) 能力模式下会失败。

本季度 fts 新增了一个 fts_openat() 入口点，它接受预先打开的目录描述符，新增了每项的 fts_dirfd 字段，并将其内部实现转换为基于文件描述符的相对操作，同时通过 ELF 符号版本化保持 ABI 兼容性。现在，遍历可以完全在 Capsicum 沙箱内运行。

作为第一个使用者，chflags 已引入 Capsicum 支持，通过 chflagsat() 在进入能力模式之前打开的描述符上执行其工作，从而将其限制在命令行指定的目录层级内。

这项工作作为 Google Summer of Code 2026 项目完成。

赞助方：Google Summer of Code 2026

为 bhyve 提供完整的 CPUID 控制

联系人：Hans Rosenfeld <[email protected]>

项目概述

该项目正在进行的工作旨在将现有的概念验证工作集成到 FreeBSD 中，并添加以下可用性功能：

像 {{NAME_ab12cd34}} 这样写入的值是真实值的占位符。请完全按照写入的形式使用它们，无论是在回复中还是在工具调用中：它们会在任何内容运行之前被替换为真实值。不要要求验证它们，也不要用示例替换它们。

• 一种用户友好的配置方法，可按需覆盖单个位、部分甚至整个 CPUID 功能，同时保留主机 CPUID 信息的其余部分或预定义的 CPUID 配置

• 一种用于配置 bhyve 所报告的 hypervisor 签名的用户友好方法

• 一组基于常见 x86 架构级别的预定义 CPUID 配置，或许还包括若干真实 CPU 型号的一组 CPUID 数据，以及一种用户友好的配置方法，可为 VM 选择其中之一

上一季度变更

配置语法在最后一刻发生了变更。不再使用 cpuid.enable 和 cpuid.disable 两个不同选项按名称启用或禁用功能，现在只有一个 cpuid.features 选项。该选项接受功能名称，可在名称前加 - 以禁用，或加 + 或不加前缀以启用功能。

除了抽象的 x86 架构模型外，还以预定义配置文件片段的形式实现了若干 CPU 型号。目前截至 Intel 的 Icelake 代和 AMD 的 Bulldozer 代。

引入更多 cpuid 配置选项以便编写 CPU 型号配置，例如用于 CPU Brand String 的 cpuid.brand，或用于覆盖供应商标识的 cpuid.vendor。

约束检查已扩展，允许为只能按数值降低的值定义位掩码。

新增配置选项 cpuid.check，用于覆盖约束检查相关的默认操作。它接受值 fail（默认）、warn、none 和 fix。

已为 x86 架构模型和所有预定义 CPU 型号添加默认缓存配置。

新的 cpuid.hypervisor 选项可轻松覆盖 CPUID 功能 0x40000000 中的 hypervisor 标识。客户机仍可从 CPUID 功能 0x40000100 查询真实的 hypervisor 标识和功能标志。

下一季度计划

• 添加更多现代预定义 CPU 型号

• 更新手册页 bhyve(8)、bhyve_config(5) 和 bhyvectl(8)。

• 使整套内容通过评审并提交到 FreeBSD。

使用 Freepascal/Lazarus 编写的 bhyve 管理 GUI

链接：Bhyvemgr URL：https://github.com/alonsobsd/bhyvemgr/ Bhyvemgrd URL：https://github.com/alonsobsd/bhyvemgrd/

联系人：José Alonso Cárdenas Márquez <[email protected]>

Bhyvemgr 是一个在 FreeBSD 上用 Freepascal/Lazarus 编写的 bhyve 管理 GUI。它需要一组工具，其中大部分安装在基础系统中，一些从 ports/packages 安装。主要目标是成为一个桌面应用，专注于桌面用户，以便在 FreeBSD 主机上轻松快速地设置并运行虚拟机。

从版本 v2.0.0 开始，bhyvemgr 迁移到客户端/服务器架构。因此，开发了一个服务器组件。这个新组件称为 bhyvemgrd。

Bhvemgrd 支持两种运行特权任务的方式：mac_do/mdo（FreeBSD >= 140000）和 mac_do/setcred/exec_paths（仅适用于 FreeBSD >= 1501501）。进程本身在非特权的 bhyvemgrd 用户下运行。

在过去两个季度中，Bhyvemgr 有许多错误修复和改进。

以下是一些新增亮点：

• 添加新的操作系统选项

• 添加在 FreeBSD >= 1500509 时使用 VNC unix sock（vnc.sock）的支持

• 添加存储快照支持（仅当启用 zfs 时）

• 改进 TPM 支持

• 迁移到客户端/服务器架构（unixsocket、json 等）。bhyvemgr 仍作为客户端，新的 bhyvemgrd 应用用作服务器。

• 移除特权函数/过程。现在它们属于 bhyvemgrd 的一部分。

• 移除 sudo/doas 支持。不再需要，因为特权任务将从 bhyvemgrd 服务触发。

• 移除 FreeBSD 13.x 支持

• 用 vncviewer（tigervnc-viewer）替换

Bhyvemgr 和 Bhyvemgrd 支持从 15.x 到 16-CURRENT 的 aarch64，以及从 FreeBSD 14.x 到 16-CURRENT 的 amd64。Bhyvemgr 可以从 sysutils/bhyvemgr 编译或安装，支持 gtk2、qt5 或 qt6 界面。Bhyvemgrd 可以从 sysutils/bhyvemgrd 编译或安装。

欢迎有兴趣帮助或支持这些项目的人。

当前 bhyvemgr 版本：2.1.0 当前 bhyvemgrd 版本：1.2.0

赞助：https://paypal.me/alonsocbsd

bsdinstall 的桌面脚本

链接：Laptop Support and Usability Project 任务 URL：https://github.com/FreeBSDFoundation/proj-laptop/issues/25 项目仓库 URL：https://gitlab.com/alfix/kde-installer-dialogs

联系人：Alfonso S. Siciliano <[email protected]>

本项目的目标是在 FreeBSD 系统安装程序 bsdinstall(8) 中提供一个简单功能，用于安装和配置图形环境。安装程序应询问用户是否要安装桌面环境，如果是，则自动安装并配置所需的一切，尽量少让用户干预或无需用户干预。重启后，应向用户显示图形登录屏幕。

在 2026 年第一份状态报告中，描述了一种可能的解决方案：一个约 400 行代码的 shell 脚本，用于安装并自动配置图形桌面环境所需的组件，包括 GPU 驱动、Xorg、KDE Plasma 和 SDDM。在收到大量用户反馈的测试征集之后，提交了审查 D56167，以将新的桌面脚本添加到 bsdinstall。

审查提交后，围绕提议的实现进行了多次讨论。作为审查的结果，有人要求将脚本拆分为更小的组件，并将部分功能移到单独的 port 中。审查 D56167 现在已

文章标题：FreeBSD 开发者 AI 调查结果

正文： 项目仓库中也已完成桌面脚本的新草案。它与原始脚本差异显著，目前大约有 100 行代码。在新增的 ports 被加入 Ports Collection 之后，将提交一项新的评审，以把桌面脚本加入 bsdinstall。

这仍是一项实验性功能。未来，根据用户的兴趣和反馈，桌面脚本可以进一步改进，以支持更多桌面环境和图形工具。

赞助方：The FreeBSD Foundation

Sylve — 面向 FreeBSD 的统一系统管理平台

链接：网站 URL：https://sylve.io GitHub URL：https://github.com/AlchemillaHQ/Sylve CI URL：https://sylve-ci.alchemilla.io Discord URL：https://discord.gg/bJB826JvXK

联系人：Hayzam Sherif <[email protected]>

Sylve 是一个面向 FreeBSD 的现代化统一系统管理平台。它提供一个集成的 Web 界面，用于管理虚拟机（通过 Bhyve）、Jails、围绕它们的网络以及 ZFS 存储。

后端使用 Go 实现，前端使用 Svelte 构建。该项目强调极小的系统占用。默认情况下，它不要求基础系统之外的任何软件包。

可选的运行时依赖仅在相应功能被使用时才需要，包括：

• devel/libvirt 用于虚拟化

• devel/qemu 用于磁盘镜像管理

• Samba 4.x（例如 net/samba424）用于 SMB 文件共享

• sysutils/swtpm 用于 TPM 模拟支持

• dns/dnsmasq 用于 DHCP 和 DNS 服务

该 port 出于方便用户考虑会引入这些依赖，但 Sylve 本身运行不需要任何依赖。

第三季度进展亮点

本季度我们发布了两个带标签的版本：8 月 24 日的 v0.3.0，交付了上一季度报告的联网、迁移、复制和备份工作；以及 9 月 7 日的 v0.3.1，后者改进了集群恢复、备份、迁移和客户机存储管理。

• 集群节点之间的迁移现在会在工作负载仍在线时传输大部分 ZFS 数据，随后进行最终的增量传输并受控切换。

• 备份现在将相关数据集和 VM 磁盘作为协调一致的代次提交，并具备更强的恢复和还原工作流。

• 新增了更深入的 ZFS 和 ARC 遥测以及计划性 S.M.A.R.T. 测试。

• v0.3.1 重新设计了 VM 存储工作流，明确了弹出和删除附件的语义。

• 新增了受保护的本地 CLI 和交互式控制台，用于常见的 VM、Jail、联网和生命周期操作。

• 内置证书和动态 DNS 管理，包括带托管 TLS 的免费 Sylve.app 主机名，以及对 Cloudflare 和 Namecheap 的支持。

• 用户文档进行了大幅修订，为所有主要功能提供了面向任务的指南。

• Sylve 现在要求 libvirt 12.5.0 或更新版本进行 VM 管理；仍然要求 FreeBSD 15.0 或更新版本。

The FreeBSD Foundation 通过一项新的资助扩大了对 Sylve 的支持，用于该平台下一阶段的部分工作。

下一季度将带来：

• 通过 Podman 实现原生 OCI 容器管理。

• 一个 App Gallery，内含用于在 Jails 和容器中部署应用的模板。

• NFS 共享和自动 ZFS 数据集调优。

• 一个用于管理集群的移动应用、从界面进行操作系统更新，以及 ZFS scrub 计划。

• 端到端测试和更清晰的迁移文档。

• 面向初学者的简化界面。

赞助方：The FreeBSD Foundation、Alchemilla Ventures（开发）、IPTechnics LLC（基础设施与测试）

Vision Accessibility

链接：无障碍手册 URL：https://docs.freebsd.org/en/books/accessibility/ 项目仓库 URL：https://gitlab.com/alfix/freebsd-accessibility/ LearnBraille URL：https://gitlab.com/-/snippets/6065143 bsddialog URL：https://gitlab.com/alfix/bsddialog

联系人：Accessibility <[email protected]> 联系人：Alfonso S. Siciliano <[email protected]>

写作形式为 {{NAME_ab12cd34}} 的值是真实值的占位符。请在回复和工具调用中完全按照写法使用它们：它们会在任何内容运行之前被填入真实值。不要要求验证它们，也不要用示例替换它们。

Vision Accessibility 是一个项目，专注于通过记录、开发并集成面向盲人和视障用户的辅助技术，来改善 FreeBSD 中的视觉可访问性。

高对比度主题

本季度，工作主要聚焦于里程碑 2：为 FreeBSD 基础系统中的 TUI 实用工具创建新的可访问主题，并支持在操作系统安装期间选择其中一个主题。

作为这项工作的一部分，开发了下一版 bsddialog，重点是改进其主题支持。主题相关代码经过了重组和改进，bsddialog_theme.h API 得到扩展，使应用程序能够更轻松、更自动地选择和自定义主题。

具体而言，库初始化过程现在使用 bsddialog_get_auto_theme()，它会自动检测要使用的主题。如果可用，可以通过集中式的系统级或用户特定配置文件选择主题。这样一来，FreeBSD 基础系统中的实用工具（如 tzsetup(8) 和 bsdinstall(8)）以及 ports（如 ports-mgmt/portconfig）就可以使用相同的主题配置，而无需对每个应用程序单独修改。

还改进或新增了几个面向可访问性的主题：

• 改进了内置的黑白主题。它最初是为不支持颜色的终端设计的，但也适用于不单纯依赖颜色来呈现信息。

• 新增了一个不含红色的主题，使用黑色、蓝色、青色、白色和黄色。

• 新增了一个不含黄色和蓝色的主题，使用黑色、绿色、红色和白色。

• 新增了一个高对比度主题，使用黑色、品红色、白色和黄色。

新功能已记录在手册页中，包含新示例，并记录在 bsddialog 的 CHANGELOG 中。

设计和实现阶段已经完成，测试现在开始。新功能目前仅在 bsddialog 仓库的 main 分支中可用。

接下来的步骤是完成测试、发布 1.2 版本、更新 devel/bsddialog port，并将新版本导入 FreeBSD BASE。

盲文显示设备

本季度，购置了一台 HumanWare BrailleNote Apex，用于后续里程碑。收到了合适的充电器，并成功测试了该设备。盲文显示器和键盘工作正常，内置语音合成器也工作正常。

尽管盲文子系统计划在未来的里程碑中实现，但初步实验已经开始，因为设计和集成这样一个子系统是一项复杂的任务。这些最初的测试旨在为其未来的设计和实现提供实用信息。

BrailleNote Apex 不仅仅是一台盲文显示器，而是一台运行 Windows Embedded CE 6.0 的盲文记事本。它通过 KeySoft 提供一维用户界面，包含文字处理器、电子邮件、网页浏览等应用程序和其他功能。Apex 还通过 VGA 连接到外部显示器，这使探索并更好地理解其功能变得更容易。

使用 Apex 需要熟悉盲文，既包括通过盲文键盘进行书写，也包括通过盲文显示器进行阅读。因此，还开发并使用了 LearnBraille。它是一个简单的 Lua 脚本，使用 devel/liblouis 提供一个用于练习盲文字符的测验。

Apex 通过 USB 连接到 FreeBSD，并在其 “Screen Reader Terminal” 模式下使用，该模式允许设备作为连接到另一台计算机的盲文显示器运行。该设备由 uipaq(4) 识别，通信通过 man:ucom interface[4] 提供。这与该设备的架构一致，因为 Apex 运行 Windows Embedded CE 6.0。

初始通信测试在双向均成功。数据从 FreeBSD 发送到盲文显示器，包括在盲文单元上呈现的简单“Hello World, FreeBSD!”消息。在盲文键盘上输入的字符也能被 FreeBSD 接收。在这个方向上，每个盲文字符由一个字节表示，其各个位对应盲文点。

进一步的测试、文档以及有关这项工作进展和结果的信息将在未来的报告中提供。

赞助方：The FreeBSD Foundation

x11appjail：用于创建、验证、安装和运行 AppJails 的工具

链接：GitHub 上的 x11appjail URL：https://github.com/DtxdF/x11appjail 联系人：Jesús Daniel Colmenares Oviedo <[email protected]>

x11appjail 是一个专用工具，用于创建、验证、安装和运行 AppJails。AppJail 是一种 CLI、TUI 或 X11 应用程序，它在 FreeBSD jail 内运行，但最终用户会认为它与直接在宿主系统上运行的应用程序完全相同（或至少非常相似）。

该工具广泛使用 appjail(1) 作为其引擎；然而，与后者不同，x11appjail 中的主要用户既不是 root，也不是特权用户，而是非特权用户。该项目的根本目标是授予用户对 jail 的有限访问

文章标题：FreeBSD 开发者 AI 调查结果

正文： 这两个工具都支持经典、久经考验的 SHA-256 算法，以及更快且安全的 BLAKE3 算法。当 sysutils/b3sum 可用时（如果 x11appjail(1) 是从 ports 安装的，则为默认情况），BLAKE3 是默认选择，除非在 rc.conf(5) 中明确指定 SHA-256。

校验和算法对 x11appjail(1) 和 appscript(1) 都至关重要。对于 x11appjail(1)，该算法用于 veriexec 等内部操作，而 appscript(1) 则用它来验证可执行文件。BLAKE3 之所以被选为默认选项，是因为它在不牺牲安全性的前提下提供了更高的速度。

• 在 x11appjail(1) 中实现了属性（attributes），作为用户和系统操作员操纵 AppJail 行为的手段。例如，系统操作员可以创建系统属性 users.uid.perms，其内容可能是 "enable_3d sound usb webcam"。非特权用户可以创建用户属性 appname:profile.allow.enable_3d 和 appname:profile.allow.sound。随后，在执行 AppJail 时，设备是否可见取决于用户是否拥有相应权限，以及是否为正在创建的 jail 授权了这些权限。在本例中，只要 AppJail 已包含使其可见的必要逻辑，硬件加速和声音设备就会变为可见。

x11appjail(1) 另一个值得一提的显著变化是 ${EXAMPLESDIR}/Apps 中添加的示例：badwolf、chromium、evince、feh、firefox、htop、linux-brave、mpv、nanonote、telegram-desktop 和 thunderbird。除了应用程序本身之外，关键因素是部署方法。htop 是 CLI 应用程序的一个例子，linux-brave 是一个 Linux 应用程序，其余则是 X11 应用程序。Web 浏览器、Mpv 和 Thunderbird 是最有趣的例子，因为它们展示了 AppJail 如何利用 VirtualGL 在 FreeBSD jail 内正确启用硬件加速，而鉴于 appjail-x11(1) 使用的后端是 Xephyr，这通常是不可能实现的。最棒的是，从最终用户的角度来看，这一切都是透明的。

演示视频：https://youtu.be/EBSMHBC0Phc

赞助：https://www.patreon.com/appjail

rdma-core 项目移植到 FreeBSD

链接：link：移植的提交系列 URL：https://github.com/linux-rdma/rdma-core/pull/1778 link：LinuxAPI 项目 URL：https://github.com/freebsd/linuxapi

联系人：Konstantin Belousov <[email protected]> 联系人：Ariel Ehrenberg <[email protected]> 联系人：Slava Shwartsman <[email protected]> 联系人：Gleb Popov <[email protected]>

远程直接内存访问（RDMA）基础设施在计算节点和存储节点之间提供高性能互连。它可以在不同的物理网络上运行，例如 Ethernet 和 Infiniband。

RDMA 协议栈的实现由若干组件组成。有核心内核基础设施，以及主机通道适配器（HCA）的驱动程序，提供对内核 verbs 的访问。用户空间应用程序从不直接与内核设备交互，核心 libibverbs 库和厂商特定的用户空间驱动程序提供统一的和设备特定的 verbs。

由于 RDMA 旨在提供低延迟、低开销的操作，高性能 HCA 从 CPU 卸载大量操作。此外，典型的在线操作（如发送和接收）可以在用户空间发起和完成，内核只协助连接的建立和拆除。因此，用户空间 RDMA 软件栈对其运行至关重要。

像 {{NAME_ab12cd34}} 这样写出的值是真实值的占位符。在回复和工具调用中都要完全按照所写的形式使用它们：它们会在任何内容运行之前被填入真实值。不要要求验证它们，也不要用示例替换它们。

FreeBSD 基础系统包含了所谓的 OFED 内核核心组件的移植、内核驱动，以及用户空间核心（libibverbs）和用户空间驱动，例如用于管理 Nvidia Connect-X4 及之后 HCA 的 libmlx5。随着时间的推移，内核部分从 Linux 内核的 infiniband 代码中获得了大量重要更新，Linux 内核的 infiniband 代码也成为更新版 OFED 的归属地。OFED 的用户空间部分被转换为 rdma-core 用户空间项目，该项目仅支持 Linux（以及 glibc）。由于 rdma-core 中的用户空间驱动提供关键功能，且 FreeBSD 用户空间 RDMA 组件相当过时，整体情况需要解决。

我们尝试通过导入一系列带依赖的 rdma-core 提交来更新树内用户空间组件，但很快证明这不可行。于是我们开始研究让 rdma-core 在 FreeBSD 上编译和运行需要做哪些工作。

首先，rdma-core 中使用了许多缺失的 glibc 特有 API，例如 strdupa() 及其同类、main:tdestroy(3)、一些 pthread 函数。这些在基础系统中很容易处理，添加它们也有利于整个 FreeBSD 移植工作。

其次，更严重的是，glibc 的不可移植特性在源码中随处可见，试图全部覆盖会产生巨大的移植补丁，这很难向上游推送，即使对合作的上游也是如此。于是，形成了使用类似内核代码中 LinuxKPI 方法的想法并加以发展，称为 LinuxAPI。与处理 Linux 内核和 FreeBSD 内核之间架构不匹配的 LinuxKPI 不同，除了不同的 C 接口之外，LinuxAPI 还需要抹平围绕 POSIX 定义的同一核心功能的扩展所带来的差异。这主要涉及 POSIX 未定义但 RDMA 运行所需的位，比如网络接口枚举，或发现支持 rdma 的设备及其能力等。

似乎人们已经认为 LinuxAPI 在 rdma-core 移植工作之外也有用，有一个项目 github.com/freebsd/linuxapi 接管了已开发的头文件集并进一步扩展。我们目前正在努力提供宽松许可证，使该库无需额外附加条件即可使用。

我们的初始目标（也受可用硬件限制）是让 rdma-core 与 ConnectX-4 卡配合工作。当然，我们欢迎所有对 FreeBSD 上的 RDMA 感兴趣的厂商改进移植，以正确支持他们的卡。

移植结果可在仓库中获取。我们也尝试将更改向上游推送，使 FreeBSD 成为 rdma-core 第二个原生支持的平台。已向该 github 项目提交 Pull Request。目前关于如何为 FreeBSD 平台组织 CI 存在一个阻塞性讨论。Gleb Popov 从分叉的源码创建了 net/rdma-core port，该 port 已进入 ports 树。

让移植工作的内核更改出乎意料地小且受控。它们主要是针对此前因没有用户空间而未被用户空间使用过的代码路径的缺陷修复。最有趣的部分或许是 Linux 和 FreeBSD 之间 ioctl(2) 行为的差异，其中 Linux 既可以返回错误又可以 copyout 数据结构。该问题已在 LinuxKPI 中被观察到，移植工作在那里提供了通用解决方案。

赞助：Nvidia networking

基于远程直接内存访问 (RDMA) 的 NFS

链接：分支 freebsd-rdma 中的最新 NFS 服务器源码 URL: https://github.com/viniciusferrao/freebsd-src.git nfs-over-rdma-setup.txt URL: https://people.freebsd.org/~rmacklem/nfs-over-rdma-setup.txt

联系人：Rick Macklem <[email protected]>, Vinicius Ferrao <[email protected]>

像 {{NAME_ab12cd34}} 这样写出的值是真实值的占位符。在回复和工具调用中完全按原样使用它们：它们会在任何内容运行之前被填入真实值。不要要求验证它们，也不要用示例替换它们。

文章标题：FreeBSD Developer AI Survey Results

正文： 目前 FreeBSD 的 NFS 支持通过 TCP（NFSv3 还支持 UDP）。本项目增加了对基于 RDMA 的 NFS 的支持，如 RFC-8166 和 RFC-8267 所述。这应能让支持 RDMA 的网卡卸载大部分网络传输工作，并在高速局域网架构上提升性能。

多亏了 Vinicius，已经取得了大量进展。他让 NFS 服务端能够工作，而且据我所知效果相当不错。

客户端现在针对 Vinicius 的服务端测试得相当好，客户端和服务端现在都已准备好进行第三方测试。要进行测试，需要一台客户端和一台服务端，配备 Mellanox ConnectX4→6 网卡，并运行从近期 FreeBSD main 源码构建的内核。

关于搭建测试环境的信息，请参阅 nfs-over-rdma-setup.txt。

再过几周，stable/15 内核应该就足以支持这些可加载模块。客户端代码也应在几周内提交到 FreeBSD 的 main，并在 2026 年底前 MFC 到 stable/15。服务端代码是通过生成式 AI 创建的，FreeBSD 项目正在制定处理生成式 AI 提交的政策。在此期间，服务端代码将作为“非官方 port”提供，用于构建内核可加载模块。

欢迎进行第三方测试。

感谢 Vinicius 完成 NFS 服务端的工作，也感谢 FreeBSD Netperf 集群的各位，没有他们我永远无法测试这段代码。

NFS 服务端代码的赞助方：Verastus HPC

nfsdtop(8) 显示谁在使用 NFS 服务端

链接：D59438 URL: https://reviews.freebsd.org/D59438 rG60c7313074b9 URL: https://cgit.freebsd.org/src/commit/?id=60c7313074b93adf4ea70ff44b78b3b4fc15c29f

联系人：Devin Teske <[email protected]>

nfsstat(1) 报告的是整个服务端的情况。nfsdtop(8) 报告的是读写操作背后的用户、组或客户端。它是一个类似 top 的显示，通过 dtrace(1) 从 nfsd(8) 的路径 nfsrvd_read、nfsvno_read、nfsrvd_write 和 nfsvno_write 采集数据。

默认视图按用户。-g 按组合并，-c 按 IPv4 客户端合并。每个间隔打印一个总计，然后打印执行了 I/O 的行，按读写合计流量排序。默认间隔为两秒。除非用 -b 请求该间隔内传输的字节数，否则各列为人性化带宽。WRITE(IN) 是客户端发送的数据。READ(OUT) 是服务端发送的数据。

        nfsdtop
nfsdtop -c
nfsdtop -g -G wheel
      

这些路径上的 UID、GID 或客户端地址属于客户端，而非服务端。nfsdtop(8) 在采样时不会调用 getent(1) 为它们命名。名称来自当前目录下的映射文件：.nfsd.passwd、.nfsd.group 和 .nfsd.hosts。过滤器（-U、-G 或 -C）只解析一次，先查这些映射文件，然后使用 getent(1) 或 host(1)，结果被编译进 dtrace(1) 谓词。

-j 每个间隔为视图总计输出一个 JSON 对象，并为每个键各输出一个，包含字节数和速率。-J 同时采样客户端、组和用户视图：

        nfsdtop -J -N 1
      

只有 root，或能运行 dtrace(1) 的用户才能运行它。客户端视图和 -C 仅支持 IPv4。-R，或非空的 NFSDTOP_REDACT，会将非众所周知系统账户的名称替换为等长的随机字符串。

该介绍自 60c7313074b9（D59438）起已在 HEAD 中，nfsdtop(8) 将在 FreeBSD 16.0 中首次发布。

感谢 Alexander Ziaee 和 Benedict Reuschling 撰写手册页，感谢 Adrian Chadd 审阅，感谢 Rick Macklem 查看 NFS 方面。

请在已经繁忙的服务端上运行它。如果你需要的行不是用户、组或客户端，请写信告知。

增强 Zoned Storage 支持

链接：GSoC 项目 Wiki 页面 URL: https://wiki.freebsd.org/SummerOfCode2026Projects/EnhancingZonedStorageSupportOnFreeBSD

联系人：voidanix <[email protected]>

项目概述

本项目旨在增强 FreeBSD 中的 Zoned Storage 支持，通过添加以下新功能：

• 用于模拟分区设备的新 gzoned(8) GEOM 驱动。

• 对分区 NVMe 驱动器的 Zoned Namespaces（ZNS）支持。

像 {{NAME_ab12cd34}} 这样写入的值是真实值的占位符。请在回复和工具调用中完全按原样使用它们：它们会在任何操作运行之前被真实值填充。不要要求验证它们，也不要用示例替换它们。

文章标题：FreeBSD 开发者 AI 调查报告

正文：

• 改进了 gconcat(8)、glabel(8) 和 gpart(8) 对 Zoned Storage 的处理。

这项工作是在 Google Summer of Code 2026 框架下开展的。

对 FreeBSD 的重要性

新的 gzoned(8) 驱动在普通非分区驱动器之上模拟 Zoned Storage，从而无需分区硬件即可进行 Zoned Storage 的开发、测试和集成。

ZNS 支持使得在 NVMe SSD 上使用 Zoned Storage 成为可能。

支持分区的 GEOM 类让主机管理的驱动器能够与常规存储工具配合使用。

状态

gzoned(8) 现已在 main 中。

ZNS 支持已添加到 nda(4) 驱动中，而由于 nvd(4) 功能过于基础，暂无为其添加支持的计划。

主机管理的设备现在可以通过 gconcat(8) 进行拼接，而 glabel(8) 由于需要元数据，会干净地拒绝为它们自动打标签。gpart(8) 现在可以通过不写入备份 GPT 表的方式，在主机管理的驱动器上创建 GPT 分区方案。

下季度计划

• 完善 gconcat(8)、glabel(8) 和 ZNS 支持，因为它们现在可以依赖 main 中的 gzoned(8)。

• 将全部工作合并到 main 中。

导师：Robert Clausecker、Alan Somers 和 Ken Merry 赞助方：Google Summer of Code 2026

FreeBSD 上的 LLDB 改进

联系人：Minsoo Choo <[email protected]>

我 5 月到 8 月因上大学而离开，现在已重新开始这项工作。由于我未能为 LLVM 23 完成此任务，完成的目标版本已改为 LLVM 24。

armv7 和 powerpc64be 目前是支持候选。一旦 LLDB 重构完成，我将实现对这些架构的支持。

与使用自定义帧嗅探器进行 trapframe 展开的 KGDB 不同，LLDB 使用 DWARF CFI。DWARF CFI 在 KGDB 上同样有效；当一个帧未被 KGDB 的帧嗅探器识别时，它会回退到 CFI。因此，KGDB 端无需任何更改。

赞助方：The FreeBSD Foundation

Procdesc：调试 API

联系人：Konstantin Belousov <[email protected]>

进程描述符 API 增强项目继续进行，目标是允许使用描述符进行完整的进程控制，尤其是调试。我希望能够停止引用 pid 作为进程标识符。其里程碑应该是演示为某个非平凡的调试器启用 capsicum 模式，我选择了 truss(1)，因为它在附加到目标后既不需要文件系统命名空间访问，也不需要网络命名空间访问。

半显然的解决方案是引入 pdptrace(2)，它等价于 ptrace(2)，但以进程描述符作为进程标识。我们需要能够获取进程调试事件的通知，这些通知由基于 pid 控制的 waitpid[2] 系统调用族提供。并且，我们需要一种方法来获取从被调试进程 fork 出的新子进程的进程描述符，以便继续跟踪所有后代。

此前已添加了 pdopenpid(2) 系统调用，它允许获取对任意进程的句柄。对进程描述符的现有操作有些有限：句柄所有者可以使用 kqueue(2) 等待退出通知，并运气好的话检索进程退出状态。

最后一点需要一些阐述。由于 pdwait(2) 调用是最近才添加的，内核中有一些 hack 允许对使用 pdfork(2) 创建的进程的 pid 调用 waitpid(2)。结果，waitpid(2) 调用者可能会在进程描述符所有者能够调用 pdwait(2) 之前就回收了该进程。类似地，如果在同一进程上打开了多个进程描述符，只有第一个 pdwait(2) 调用者能够通过 pdwait(2) 检索退出状态，从而使其他描述符变得无用。

像 {{NAME_ab12cd34}} 这样写入的值是真实值的占位符。在回复和工具调用中都请按原样使用它们：它们会在任何运行之前被填入真实值。不要要求验证它们，也不要用示例替换它们。

FreeBSD 开发者 AI 调查结果

所列出的这组问题也使得正确使用所提出的 pdptrace(2) 变得非常困难。被调试的进程可能会从进程描述符中窃取事件，反之亦然。简单地禁止对已打开描述符的进程调用 wait(2) 并不可行，原因有两个： 向后兼容性，waitpid(2) 早已被允许，且现有二进制文件依赖它 如果被调试对象使用 fork(2) 创建了子进程，它期望从 wait(2) 获得退出通知（例如 SIGCHLD）和退出状态

解决方案是多方面的。首先，只要存在已打开的进程描述符，我们就必须推迟回收；或者如果进程是用 fork(2) 创建的，则在父进程对该 pid 调用 wait(2) 之前不应回收。其次，退出状态需要在回收之后仍保留在进程描述符的私有数据中，以便对任意描述符调用 pdwait(2)。这是通过在内核 struct proc 上提供一个“僵尸引用”位图来实现的。每个僵尸引用都会阻止回收，并通过相应的 waitpid(2) 或 pdwait(2) 调用清除。只有当所有已注册的引用都被清除后，僵尸进程才能被回收。如果进程是用 pdfork(2) 创建的，或用 pdopenpid[2] 打开的，它会获得 procdesc 僵尸引用。如果进程是用 fork(2) 创建的，它会获得“parent”僵尸引用。默认情况下，pdfork[2] 也会设置 parent 引用以允许 waitpid(2)，这是为了兼容性。新的 pdfork(2) 标志 PD_NOWAITPID 会阻止这一点。

然后，类 wait 事件必须能与进程描述符配合工作。procdesc 的 kqueue(2) 事件过滤器被扩展了 NOTE_PDSIGCHLD 提示，用于报告 pdwait(2) 可以在描述符上获取跟踪或退出事件。

随后，pdptrace(2) 能够有效地控制目标。新增的一个用于获取已附加进程列表的 ptrace 调用 PT_GET_CHILDREN 使 pdptrace(2) 能够掌握 fork 出的进程。

在所有功能实现之后，便可以将 truss(1) 转换为只使用进程描述符来控制被跟踪的进程。使用 pid 的现有模式被保留下来，并可通过 '-y' 选项选择，作为应急开关，也便于对新模式进行比较和调试。

赞助方：The FreeBSD Foundation