FreeBSD发展规划(202x)
2022-01-19 09:57:08 阿炯

本文专门用于记录FreeBSD项目的发展战略规划,侧重于技术方面,截止到2030年之前。

C/C++默认编译器更改为Clang

FreeBSD 最早内置的是 Gcc。从 2012 年的FreeBSD 9.0开始引入了 clang、但没有作为默认项,并且发行版本身还是继续使用 gcc 编译。从 FreeBSD 10.0 (2014 年)开始使用 clang 作为默认项,并且 x86、x64 架构发行版使用了 clang 编译内核(注意仅仅是编译内核,因为生态内大量的软件有此依赖,出于种种原因并不能完全放弃 gcc)。此时 gcc 还是保留的,特殊架构(比如 ARM、MIPS)和周边生态还是会依赖于此。再之后的版本就是逐渐从 gcc 过渡到 clang 的过程,从 FreeBSD 13.0 (2021 年)开始所有架构的发行版都开始使用 clang 编译,彻底移除了 gcc。但仍可以通过 ports 自行安装 gcc。

另外需要注意的是 2007 年以后的发行版内置的 gcc 万年不变都是 4.2.1(更高版本由于其许可协议 GPLv2 变为 GPLv3,带来了很多商业上的问题)。所以现在的BSD操作系统推荐的都是 clang。根据  FreeBSD 2012 第一季度的状态报告显示,来自 LLVM 的 Clang 编译器将成为 FreeBSD 10 的默认 C/C++ 编译器,废弃使用 GPL 授权协议的 GCC,而 Clang 的授权协议是 BSD。在stackexchange上有关于该转换的讨论。

Clang 是一个 C++ 编写、基于 LLVM、发布于 LLVM BSD 许可证下的 C/C++/Objective C/Objective C++ 编译器,其目标(之一)就是超越 GCC。OpenBSD默认搭载的编译器也是clang

FreeBSD 网桥 if_bridge 实现性能提高 5 倍

FreeBSD 在企业网络基础架构中的性能很好,但是网络桥接设备内核代码 if_bridge 处会遇到性能瓶颈(if_bridge 可以有效地将 FreeBSD 机器变成交换机)。2020年4月,开发人员研究过程中发现,当前的 if_bridge 实现在单个 BRIDGE_LOCK 互斥锁上有很大的竞争。if_bridge 实现将吞吐量限制为每秒约 370 万个数据包。

在遍历了一些选项之后,开发人员的最终解决方案利用了 FreeBSD 13 (CURRENT) 中的 epoch (9),通过巧妙地使用并发,epoch (9) 允许安全使用受保护的数据结构,而根本不需要获得锁(互斥锁或读写锁)。最终结果是,新的 if_bridge 实现每秒可以转发约 1860 万个数据包,性能大约提升了 5 倍。FreeBSD 基金会在博客上介绍了这一改进,在此研究过程中,基金会通过社区赠款提供了资助,详情查看这里

FreeBSD项目团队发布2020的五年的技术规划

2022年1月中旬消息,为了更好地支持 FreeBSD 项目,FreeBSD 基金会团队与基金会董事会以及 FreeBSD 核心团队举办了战略会议,通过复盘 FreeBSD 核心团队的用户和开发者调查结果,并与开发者、用户和 FreeBSD 社区的其他成员进行交流,以确定其工作重点——总体目标是扩大和增强技术团队的实力。


根据从个人和商业用户收集到的意见以及市场趋势,FreeBSD 基金会制定了一份时间跨度近 5 年的技术路线图 (Technology Roadmap),主要囊括四个方面:
面向终端用户的改进(特指笔记本和台式机)
商用服务器
工具和应用
虚拟化和容器


终端用户的改进


优化 Wi-Fi 性能:这是基金会正在努力填补的空白领域。他们请到了 Björn Zeeb,目的是让 FreeBSD 支持在 LinuxKPI 层使用较新的英特尔芯片(由双许可供应商驱动程序支持的芯片)
改进 DRM 图形堆栈
帮助改进 pkgbase 项目
支持 Thunderbolt 3 / USB 4
改进软件包系统、端口树 (ports tree),包括每个版本的存储仓库、改进的 CI 和测试以及漏洞缓解工具的集成

商用服务器


在商用服务器方面,基金会表示将继续投资支持 Tier 1 CPU 的工作,包括一般的错误修复和性能改进。这将包括对 Tier 1 级别架构供应商的新 CPU 的基础硬件支持,以及对新指令集架构级功能的支持。此外,基金会的技术团队也会投入时间改进安全性,包括安全建议、主动漏洞缓解措施,以及模糊测试工具(Syzkaller, KASAN 和 KMSAN sanitizers)。

最后,基金会将持续增加对 CI 和 Release 工具的支持,改进 FreeBSD 的自托管 CI 构建和测试环境。未来他们有多个与 CI 相关的重点领域。包括:通过托管 CI 工具 (Cirrus-CI) 和 Clang/LLVM 等项目的 CI 运行器加强对第三方项目的支持。确保自托管的 CI 环境可以作为下游项目的模板。此外,还会把基金会的原型硬件 CI 实验室基础设施投入生产环境。

工具和应用


这部分工作的主题包括,确保 FreeBSD 仍然是令人信服的平台,以便下游项目使用 FreeBSD 或 FreeBSD 的一部分作为其工作基础。和往常一样,FreeBSD 团队在特定领域所做的工作通常是开发者社区没有解决的工作。

基金会已经资助了 Moritz Systems 公司在 FreeBSD 中开发 LLDB 调试器方面的工作。已完成的工作集中在稳定性和可维护性的改进上,其次是对 Arm64 的支持和 userland 调试的改进。最终的预期结果是 LLDB 在 userland 调试方面处于良好的状态,现在他们已经把精力转移到增加实时和核心转储的内核调试支持。

调试器之后,将开始评估性能分析和工具方面的工作。

虚拟化和容器


团队现在已开始着手改进 bhyve 管理程序,包括改进凭证管理。此项工作是实现更好的 jail 集成和以非 root 身份运行 bhyve 的开始。

此外正在研究对虚拟文件系统的支持,并期望帮助整合长期以来的树外开发工作,包括快照和迁移支持,以及 arm64 架构的 bhyve。当然也正处于研究概念验证的早期阶段,以确定 FreeBSD 基金会的支持在哪些方面能够最好地满足终端用户将现代容器概念应用于 FreeBSD 的需求。

FreeBSD 内核重新引入 WireGuard 支持


2022年10月下旬消息,早在 2020 年末,FreeBSD 就引入了开源 VPN  WireGuard 支持。但随后在 FreeBSD 13 的候选版本阶段,由于对其初始实现质量的担忧 , 其内核 WireGuard 驱动程序又被删除。WireGuard 是一个易于配置、快速且安全的开源 VPN,,代码行数少,优先考虑性能,配置简单,在配置简单的同时提供高性能。

但据外媒 Phoronix 报道,FreeBSD 已重新引入了新的 WireGuard 驱动程序实现,并开始对 2020 年的代码状态进行了许多修复/改进。新 WireGuard 驱动程序由 FreeBSD 与 Jason Donenfeld 等上游 WireGuard 开发人员合作开发,它类似于 WireGuard Linux 内核驱动程序,基于内核的实现会比基于用户空间的替代实现快得多。

通过该合并可以看到,7.6k WireGuard 内核驱动代码已出现在 FreeBSD 主线中,将在 FreeBSD 14 中实装。

FreeBSD 为 SYSINT 采用合并排序取代冒泡排序

FreeBSD 维护者 Colin Percival 于2023年8月下旬发帖称,其已经为 SYSINIT 采用合并排序 (mergesort) 来取代冒泡排序 (bubblesort)。

SYSINIT 是通用调用排序和调度机制的框架,FreeBSD 目前使用它来动态初始化内核。当加载内核或其模块之一时,SYSINIT 允许在内核链接时对 FreeBSD 的内核子系统进行重新排序、添加、删除和替换,而无需编辑静态排序的初始化路由并重新编译内核。该框架还允许内核模块(目前称为 KLD)在引导时单独编译、链接和初始化,甚至在系统运行时加载。该操作使用 “内核链接器” 和 “链接器集” ("kernel linker" and "linker sets") 来完成。

Colin Percival 表示使用合并排序后的运行速度比之前快了大约 100 倍。他此前解释过更换算法的原因,当 FreeBSD 内核在 Firecracker(单核 CPU、128 MB RAM)中启动时,会花费 7% 的时间在其 SYSINIT 上运行冒泡排序。当对一千多个项目进行排序时,O (N^2) 会变得非常复杂,所以需要用更快的算法取代冒泡排序。

FreeBSD团队称考虑在基础系统采用Rust

FreeBSD 开发者在2024年1月考虑允许在其基础系统中使用 Rust 编程语言的好处和成本。邮件提及在 FreeBSD 基础系统使用 Rust 的主要缺点是构建时间加倍。这是因为需要编译基于 LLVM 的 Rustc 编译器和 Rust 的所有附加功能,这些操作使得基础系统的构建时间大约是当前的两倍。

如果 FreeBSD 基础系统采用了 Rust,开发者可以重新 Rust 重写许多组件 —— 而不是使用 C++,例如 ZFS 守护进程 (zfsd)、重写 devd、WiFi 用户空间代码也可以受益于用 Rust 编写,等等。列举部分如下:
* ctl-exporter (I started this, but discovered that the CTL stats API is unstable, so it can't live in ports. Instead, I had to do it in C).

* fusefs tests. Absolutely impossible to do in C.  I considered Rust, but went with C++ so they could live in base.  They are too closely coupled to fusefs(5) to live out-of-tree.

* devd. Currently C++, but imp suggested a rewrite.

* zfsd. Currently C++, but I've long pondered a rewrite.  Using Rust would make it more testable.

* nscd. Currently C, but confusing and with no test coverage.  I've contemplated a rewrite myself, but I don't want to do it in C.

* The userland portion of the 802.11ac and Lightning stacks.  scottl suggested that these were good candidates for Rust.

* freebsd-kpi-r14-0.

社区正在为是否“锈化”而激辩

FreeBSD社区在2024年8月讨论是否将 Rust 语言纳入基础系统(base system),以改善系统的安全性和可维护性。与其在 Linux 上遭遇挫折不同,FreeBSD 操作系统内核和用户空间是作为基础系统一起开发的,并在 FreeBSD 源代码树(通常称为 “src”)中维护。这意味着,为了讨论使用 Rust 作为 FreeBSD 内核或基础系统中其他程序/实用程序的语言,Rust 工具链也需要存在于基础中。目前FreeBSD 基础系统支持的语言包括汇编、C、C++、Lua 和为 sh 编写的 shell 脚本。过去 Perl 也是基础系统的一部分,但在 2002 年 FreeBSD 5.0 之前被移除。

FreeBSD 还拥有一个第三方软件的 ports 集合,这些软件并非由 FreeBSD 本身维护,包括 Apache HTTP Server、Xwayland 等等。Rust 已经存在于 ports 系统中,许多用 Rust 语言编写的应用程序也是如此。在 FreshPorts 上搜索,会列出 ports 集合中的新软件包,结果显示 ports 系统中有 500 多个用 Rust 编写的软件包。这一讨论始于 2024 年的早些时候,并在 8 月份再次受到关注。

Alan Somers 展示了将 Rust 代码集成到基础系统中的示例,但这一提议并未获得广泛的支持。他表示如果 FreeBSD 基础系统采用了 Rust,开发者可以重新 Rust 重写许多组件 —— 而不是使用 C++,例如 ZFS 守护进程 (zfsd)、重写 devd、WiFi 用户空间代码也可以受益于用 Rust 编写等等。但也有开发者认为,将 Rust 语言和其工具链纳入基础系统将会带来很多问题,例如与现有 LLVM 版本的兼容性问题,以及是否应该在基础系统中支持整个 Rust 生态系统。一些开发者提出,应该优先考虑移除基础系统中的工具链,而将 Rust 编写的程序保留在 ports 集合中。

此外,有人担心 Rust 语言的快速发展可能会导致与现有代码的兼容性问题,尽管 Rust 的版本策略和编 ITION 概念旨在解决这些问题。Rust 社区通过版本策略和编 ITION 概念来确保向后兼容性,这有助于解决与现有代码的兼容性问题。但在 FreeBSD 社区中,对于如何维护 Rust 代码的长期稳定性和兼容性仍然存在争议。同时美国国防高级研究计划局 DARPA 正在研究一个名为 TRACTOR 的项目,用于自动将 C 代码转换为 Rust 代码,但这一项目并不一定成功,因为它依赖于高度先进的技术,如 LLMs 和形式验证。

这一次大讨论,又无果而终,不过预估这一话题还会再次被提起。

发布计划重大调整:支持周期缩短,发布更频繁

发布计划和支持时间表的重大变化,FreeBSD 的发布工程负责人 Colin Percival 在2024年7月与社区的交流中宣布了这些调整,以下是具体内容。

缩短支持周期:从 FreeBSD 15.x 开始,稳定分支的支持期限将从五年减少到四年。这一变更旨在更好地与 FreeBSD 安全和 Ports 团队的能力相匹配,这些团队在同时管理超过两个稳定分支时面临挑战。

更频繁和更可预测的发布:此外FreeBSD将引入更可预测的发布计划。未来该项目将在每个支持的稳定分支中几乎每季度发布一个小版本。根据新计划,发布过程通常包括三个 BETA 版本和一个发布候选版本(RC),这比以前最多六个 RC 的计划更加简化。自 2023 年 11 月接任发布工程负责人以来,Percival 解释说,这些变化源于对发布过程和时间表的全面审查。更频繁的发布将有助于发布过程,因为如果下一个小版本在六个月后发布,而不是一年或更长时间后发布,这样可以减少对“最后时刻添加功能”的压力。

修订后的流程旨在确定发布周期的起点,为长期规划提供有价值的参考。尽管具体的发布日期可能会因关键错误修复而有所调整。

即将发布的版本计划
更新的计划概述了几个即将发布的版本,例如:
FreeBSD 13.4 将于 2024 年 9 月发布,EoL(生命周期终止)在 2025 年 6 月。
FreeBSD 13.5 将于 2025 年 3 月发布,EoL 在 2026 年 4 月。
FreeBSD 14.1 将于 2024 年 6 月发布,EoL 在 2025 年 3 月。
FreeBSD 14.2 将于 2024 年 12 月发布,EoL 在 2025 年 9 月。
FreeBSD 14.3 将于 2025 年 6 月发布,EoL 在 2026 年 6 月。
FreeBSD 14.4 将于 2026 年 3 月发布,EoL 在 2026 年 12 月。
FreeBSD 14.5 将于 2026 年 9 月发布,EoL 在 2027 年 6 月。
FreeBSD 14.6 将于 2027 年 3 月发布,EoL 在 2028 年 11 月。

FreeBSD 15.0 作为一个主要版本,计划在 2025 年 12 月发布,EoL 在 2026 年 9 月。

需要澄清的是,FreeBSD 版本 13.5 和 14.6 将分别支持至 13.0 和 14.0 发布后的五年。

这一结构化时间表确保了每个发布阶段——从代码冻结到最终发布——都在一个季度内完成,促进更顺利的过渡和更好的可预测性。发布计划的清晰性预计将通过允许更定期的更新和更快速地集成新功能和修复,增强 FreeBSD 的整体稳定性和安全性。

获得来自 STF 的近 70 万欧元投资

德国主权技术基金 Sovereign Tech Fund (STF) 于2024年8月已同意向 FreeBSD 项目投资 686,400 欧元,以推动基础设施、安全性、法规合规性和开发人员体验的改善。这项工作由 FreeBSD 基金会组织和管理,STF 将为 FreeBSD 提供资金直至 2025 年,重点关注五个方面:
1.零信任构建:增强工具和流程
2.CI/CD 自动化:简化软件交付和运营
3.减少技术债务:实施工具和流程,降低技术债务
4.安全控制:现代化和扩展安全构件,包括 FreeBSD Ports 和软件包集,以帮助符合法规要求
5.SBOM 改进:增强并实施 FreeBSD SBOM 的新工具和流程

FreeBSD 基金会执行董事 Deb Goodkin 称:
“这笔重大投资将进一步增强 FreeBSD 开发者和用户的安全性和基础设施。三十年来,FreeBSD 项目再次将自己定位为开源安全、弹性和可靠性的先锋。世界各国政府都认识到,像 FreeBSD 这样的开源项目在我们共享的数字基础设施中发挥着关键作用。这项由 STF 委托的工作将为面临新法规的 FreeBSD 商业用户以及公共部门、学术界和个人用户提供必要的可视性、可审计性和可信度。”

此前,STF 已陆续为 GNOME、PHP、Rustls、Coreutils uutils 等其他开源项目提供了资金;以及宣布面向小额开源项目开放投资,为个人开源维护者设立奖学金计划