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。
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.
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。
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.