这是 2019 年第三季度的状态报告。
本季度，由于组织更为高效，报告团队比以往更加活跃：我们定期发送了报告通知和提醒，报告也得到了快速审核和合并（在此特别感谢 debdrup@ 在审核工作中的贡献）。
在社区的帮助下，我们仍可以进一步提高效率。季度团队发现，许多报告都是在截止日期前的最后几天甚至截止后才提交的。为此，我请社区成员遵循以下指南，以帮助我们更早地发布报告：
在收到第一次报告通知（截止日期前 1 个月）时，先提交报告的初稿。
在收到提醒时（通常在截止日期前 2 周和 1 周），如有需要，请更新你的报告。
如果在截止日期后仍有一些更新，请联系团队（可以通过 IRC 的 #freebsd-wiki 或发送邮件至 monthly@）请求他们暂缓处理，前提是你认为这些更新很紧急；否则，请将这些更新整理为下一季度报告的草稿。
从下个季度开始，所有季度状态报告将改为在季度的最后一个月内准备完成，而不再是在季度结束后的第一个月内完成。这意味着提交报告的截止日期将分别定在 1 月、4 月、7 月和 10 月的第一天。
因此，下个季度将是一个较短的季度，仅涵盖 11 月和 12 月，报告可能会在 1 月中旬发布。
——Lorenzo Salvadore
以下内容摘自各个官方及半官方团队，详情请参见 管理页面。
联系人：集群管理团队 <clusteradm@FreeBSD.org>
FreeBSD 集群管理团队由负责管理项目依赖的分布式工作和通信同步所需机器的人员组成。本季度，团队开展了以下工作：
更改 TWN 站点的 IPv6 地址。
解决了 KWC 站点的硬件问题（与 hrs@ 合作）。
将剩余的基础设施从 YSV（雅虎！）站点迁移到 NYI（纽约互联网）（peter@）。
YSV 在 2000 年到 2019 年期间托管了 FreeBSD.org 的大部分内容。
在 FreeBSD 基金会的支持下，为 portmgr@ 安装了新机器。
解决了 GitHub 导出器、 Bugzilla 以及 hg-beta 的中断问题（感谢 uqs@ 和 bapt@）。
PowerPC64 服务器已上线（power8），用于构建软件包及作为参考主机。
正在进行的系统管理工作：
为新的提交者创建账户。
对关键基础设施进行备份。
跟进第三方软件的安全更新。
正在进行中的工作：
审查服务 jail 和服务管理员的操作。
南非镜像（JINX）项目正在推进中。
解决 PowerPC64 Power9 上的 NVME 问题，该问题阻碍了双插槽机器作为软件包构建器的使用。
在 FreeBSD 基金会支持下，为软件包构建器（SSD）进行驱动升级测试。
解决 Aarch64 参考机器的启动问题。
在芝加哥地区建立由 NYI.net 赞助的新共置机房。
为 CI 预发布环境设置新的主机。
联系人：Jenkins 管理员 <jenkins-admin@FreeBSD.org> 联系人：許立文 <lwhsu@FreeBSD.org>
FreeBSD CI 团队负责维护 FreeBSD 项目的持续集成系统及相关任务。该 CI 系统定期检查已提交的更改是否可以成功构建，然后对构建结果进行各项测试和分析。构建作业的结果会存档在构件服务器中，以满足后续的测试和调试需求。CI 团队成员会对失败的构建和不稳定的测试进行检查，并与该领域的专家协作，修复代码或调整测试基础设施。有关这些工作的详细信息，请参阅每周的 CI 报告。
在 201909 开发者峰会 上，我们成立了一个测试工作组，lwhsu@ 在会上展示了 Testing/CI 项目的现状以及“如何使用 FreeBSD CI 系统”，相关幻灯片可在开发者峰会页面上查看。一部分内容已迁移到 https://wiki.freebsd.org/Jenkins/Debug，欢迎大家扩展和补充。
我们将继续发布 CI 每周报告，并已将归档迁移至 https://hackmd.io/@FreeBSD-CI。
正在进行中的工作：
在 https://hackmd.io/bWCGgdDFTTK_FG0X7J1Vmg 收集并整理 CI 任务和想法
搭建 CI 阶段环境，并在其上部署实验性作业
扩展并发布嵌入式板卡测试平台
在裸金属硬件上实现自动测试
增加对 -CURRENT 分支的 drm Port 构建测试
在 https://github.com/freebsd/freebsd-ci/pulls 上测试并合并拉取请求
规划运行 ztest 和网络堆栈测试
通过托管 CI 解决方案，帮助更多第三方软件在 FreeBSD 上实现 CI
有关更多正在进行中的信息，请参阅与 freebsd-testing@ 相关的工单。
该项目由 FreeBSD 基金会赞助。
联系人：FreeBSD 核心团队 <core@FreeBSD.org>
FreeBSD 核心团队是 FreeBSD 的管理机构。
核心团队已初步同意在某些情况下使用 BSD+ 专利许可。对于引入新的 BSD+ 专利许可组件或将现有组件的许可更改为 BSD+ 专利许可，必须经过核心团队的批准。 https://opensource.org/licenses/BSDplusPatent
内核伪随机数生成器（PRNG）的维护权已进行调整，以降低对在该领域表现出能力的提交者的贡献门槛。
核心团队已批准为 Paweł Biernacki 分配源代码提交权限。Konstantin Belousov <kib@> 将担任 Paweł 的导师，而 Mateusz Guzik <mjg@> 将作为联合导师。
由核心团队发起的 Git 过渡工作组在上个季度召开了会议，但报告尚未发布。相关讨论将在 2019 年第四季度继续进行。目前仍需解决的诸多问题包括如何处理 contrib/ 目录、是否需要在当前的 Git 仓库中重新生成哈希，以及如何最佳地实现提交测试。
联系方式：Deb Goodkin <deb@FreeBSDFoundation.org>
FreeBSD 基金会是一家 501(c)(3) 非营利组织，致力于在全球范围内支持和推广 FreeBSD 项目及其社区。其资金来源于个人和企业的捐赠，这些资金用于赞助和管理软件开发项目、组织会议和开发者峰会，并为 FreeBSD 的贡献者提供差旅补助。基金会还负责采购和维护硬件，以改进和维护 FreeBSD 的基础设施，同时提供资源以加强安全性和质量保证工作；出版营销资料以推广、普及和倡导 FreeBSD 项目；促进商业厂商与 FreeBSD 开发者之间的合作；最后，以具备法律实体身份的形式代表 FreeBSD 项目签订合同、许可证协议以及处理其他需要法律认可的事务。
以下是我们上个季度为支持 FreeBSD 所做工作的部分亮点：
我们积极促进商业用户与 FreeBSD 开发者之间的合作，同时也与企业会面讨论其需求，并将这些反馈传递给项目组。在第三季度，Ed Maste 和 Deb Goodkin 在美国与几位商业用户进行了交流。这不仅有助于上述目标，也让我们更好地了解 FreeBSD 的实际应用场景。此外，我们还在 vBSDCon 和 EuroBSDCon 与众多商业用户进行了会面，这些场合为与商业及个人用户以及 FreeBSD 贡献者交流提供了绝佳机会。
我们的所有工作均完全依赖于你的捐赠。我们正不断努力，争取更多商业用户的回馈，以便持续支持 FreeBSD。更重要的是，我们要感谢那些在上个季度捐赠了 10 美元至 1,000 美元的个人捐赠者，总捐款额已超过 16,000 美元！
请考虑捐赠，以帮助我们持续并加大对 FreeBSD 的支持！
此外，我们还推出了合作伙伴计划，为较大规模的商业捐赠者提供更多福利。更多信息请访问 www.FreeBSDfoundation.org/FreeBSD-foundation-partnership-program/，并与你的企业分享。
基金会通过全职技术人员、承包商以及项目赞助获得者，支持一系列旨在改进 FreeBSD 操作系统的软件开发项目。他们负责维护和改进关键的内核子系统，添加新特性和功能，并解决各种问题。
在上个季度，FreeBSD 基金会赞助的 FreeBSD 基本系统代码库共提交了 345 次提交，这大约占该期间所有提交的五分之一。许多项目在本季度报告中已有独立条目（此处不再赘述）。
Konstantin Belousov（基金会工作人员）对多个内核子系统以及低级 32 位和 64 位 x86 基础设施做出了大量改进，这些改进包括对健壮互斥锁、 unionfs、内存不足（OOM）处理程序以及每 CPU 分配器的修复。
另外，还有针对安全问题的修复、漏洞缓解措施的引入与维护，以及对 POSIX 兼容性的改进。
Ed Maste 提交了一系列较小的安全漏洞修复和改进，同时也推出了用于编辑漏洞缓解控制 ELF 注记的首个工具版本。其他工作还包括对构建基础设施和工具链的改善。
作为淘汰 GNU binutils 2.17.50 中汇编器的一部分，现在 Clang 的集成汇编器（IAS）得到了更广泛的应用，而 readelf 工具也能解析更多 ELF 注记信息。
Ed 还在 arm64 平台上启用了 Linux 二进制兼容层，并为 renameat2 系统调用提供了一个简单实现（支持常见选项）。
Mark Johnston 为多个 ELF 工具链实用程序添加了 Capsicum 支持，并提交了许多其他与 Capsicum 相关的内核和用户空间修复。
Mark 还致力于一系列与安全改进相关的修改，包括整合并支持 Syzkaller 自动系统调用模糊测试工具以及修复 Syzkaller 发现的问题。其他修改还包括解决因引用计数回绕导致的故障、改进 prot_max 内存保护，同时也在 NUMA、锁机制、内核调试、RISC-V 以及 arm64 内核的改进方面贡献良多。
Edward Napierala 在整个季度中继续推进 Linuxulator 的改进。主要工作集中在工具改进上——现在使用 strace 来诊断在 Linuxulator 下运行的 Linux 二进制文件的问题更加高效。与此同时，在改进过程中也修复了不少问题，这些通常是小问题但却带来了较大影响——例如，此前所有使用最新 glibc 链接的二进制文件在启动时都会发生段错误，现在这一问题已得到解决。
基金会配备了一名全职工作人员，专注于改进我们的自动化测试、持续集成以及整体质量保证工作。
持续改进 CI 基础设施
在 2019 年第三季度，基金会工作人员继续改进项目的 CI 基础设施，与贡献者合作修复失败的构建和测试案例，并与项目中的其他团队合作，满足他们的测试需求。我们新增了多个 CI 任务，并推动硬件回归测试实验室的建设。
許立文在 201909 DevSummit 发表了《Testing/CI Status Update》和《How to Work with the FreeBSD CI System》两个演讲，可在 DevSummit 页面查看幻灯片。
我们继续在 freebsd-testing@ 邮件列表上发布 CI 每周报告，并提供存档。
更多已完成的工作和详细信息，请参阅本报告的 FreeBSD CI 章节。
支持 FreeBSD 基础设施
基金会提供硬件和支持，以改善 FreeBSD 的基础设施。上一季度，我们继续支持遍布全球的 FreeBSD 硬件。
FreeBSD 宣传与教育
基金会的很大一部分工作致力于推广 FreeBSD 项目，包括：
宣传社区成员在 FreeBSD 方面的贡献；
编写宣传材料，帮助人们了解 FreeBSD，使他们更容易入门或参与贡献；
组织并鼓励 FreeBSD 贡献者参加活动，主持 FreeBSD 展台，并进行演讲。
基金会赞助了全球众多会议、活动和峰会，包括 BSD 相关活动、开源技术大会以及面向弱势群体的技术活动。对于 FreeBSD 主题活动，我们提供支持，以促进知识共享、项目协作以及开发者与商业用户的互动，从而维护健康的生态系统。对于非 FreeBSD 主题活动，我们借此推广 FreeBSD，提升其在不同应用场景中的影响力，并招募更多贡献者。
以下是基金会在上一季度的部分宣传与教育活动：
作为行业合作伙伴赞助 USENIX 2019 年度技术大会
在美国俄勒冈州波特兰的 OSCON 2019 代表 FreeBSD
在台湾的 COSCUP 2019 代表 FreeBSD
在美国加州圣地亚哥的 Open Source Summit 发表演讲
基金会执行董事 Deb Goodkin 接受 TFiR 采访：FreeBSD 在 Open Source Summit 上遇见 Linux
赞助 vBSDcon 2019（弗吉尼亚州雷斯顿）的 FreeBSD Hackathon
赞助并参与 vBSDcon 2019，提供参会者礼包
在泰国清迈的 APNIC-48 代表 FreeBSD
在蒙古乌兰巴托的 MNNOG-1 代表 FreeBSD
担任 FreeBSD 项目的谷歌编程之夏管理员（详情请见报告中的相关章节）
赞助 EuroBSDCon（挪威利勒哈默尔）的 FreeBSD 开发者峰会
赞助并参与 EuroBSDcon 2019（挪威利勒哈默尔）
申请并成功获得 2020 年 1 月 14 日在澳大利亚黄金海岸的 linux.conf.au 上举办 FreeBSD Miniconf 的资格
我们的 FreeBSD 主题演讲被 seaGL（西雅图）大会接受，时间为 11 月 15-16 日
此外，我们持续制作 FreeBSD 宣传材料，帮助大家推广 FreeBSD。更多关于全球范围内的 FreeBSD 宣传工作，请访问：FreeBSD Around the World。
我们的“Faces of FreeBSD”系列文章回归，最新一期：Roller Angel。
更多会议回顾和旅行报告，请参阅我们的每月通讯：FreeBSD Foundation Newsletter。
基金会还通过出版专业制作的 FreeBSD Journal 来推广 FreeBSD。该期刊现已免费开放，最新内容请访问：FreeBSD Journal。
更多基金会参加的活动及即将举办的活动信息，请访问：FreeBSD Foundation Events。
FreeBSD 周边商店上线
我们正式开设了 FreeBSD 周边商店，提供贴纸、T 恤、马克杯等商品：ShopFreeBSD。
网站改进
我们与新的网站开发人员合作，优化网站结构，使社区成员更容易找到信息，并提升网站效率。
法务/FreeBSD 知识产权
基金会持有 FreeBSD 商标，并负责其保护工作。同时，我们为核心团队提供法律支持，以解答相关法律问题。
更多关于基金会如何支持 FreeBSD 及如何帮助你的信息，请访问：FreeBSD Foundation 官网。
联系人：FreeBSD 图形团队 <x11@freebsd.org>
联系人：Niclas Zeising <zeising@freebsd.org>
FreeBSD X11/Graphics 团队负责维护 FreeBSD 图形栈的底层部分，包括图形驱动、MESA OpenGL 实现等图形库、X.org xserver 及相关库和应用程序，以及 Wayland 及相关库和应用程序。
在最近的开发周期内，我们进行了多项变更，其中大部分是幕后工作。此外，我们还清理了已被上游弃用的旧版 xorg ports。
xorg ports 及其依赖的 ports 体系结构已更新。我们将 USE_XORG 和 XORG_CAT 迁移到 USES 框架，而不再使用 bsd.port.mk 中的 bsd.xorg.mk。此项基础设施改动较大，新的 ports 若依赖 xorg ports，需在 makefile 中添加 USES=xorg。作为调整的一部分，bsd.xorg.mk 进行了拆分，XORG_CAT 部分被独立为 USES=xorg-cat，用于 xorg ports 的构建环境。此外，我们新增了从 freedesktop.org GitLab 直接拉取 xorg ports 的机制，使我们可以更方便地创建未发布版本的 ports，从而改进开发与测试。未来，我们还将推进 xorg ports 由 meson 取代 autotools 进行构建，目前此工作仍在进行中。
我们还清理并弃用了多个旧版 xorg ports 和库。其中，x11/libXp 影响较大，需要修复多个依赖。此外，我们还弃用了 x11/Xxf86misc、x11-fonts/libXfontcache 和 graphics/libGLw 等旧版库，同时部分应用程序和驱动也已被弃用。待完成剩余的移除工作后，我们的 xorg ports 将与上游保持同步。目前，我们正在评估是否有新的上游软件需要移植到 FreeBSD。
此外，我们仍然保持每两周一次的例行会议。
欢迎有兴趣参与的朋友加入我们，可以通过 x11@FreeBSD.org 邮件列表联系，或者在 gitter 聊天室：https://gitter.im/FreeBSDDesktop/Lobby 找到我们。我们还活跃在 EFNet 的 #freebsd-xorg 频道。
我们的团队在 GitHub 上也有工作仓库：https://github.com/FreeBSDDesktop。
联系人：FreeBSD 发行工程团队 <re@FreeBSD.org>
FreeBSD 发行工程团队负责制定并发布 FreeBSD 官方发行版的发布时间表，宣布代码冻结，并维护相关分支等工作。
2019 年第三季度，FreeBSD 发行工程团队完成了 11.3-RELEASE 发布周期，最终构建于 7 月 5 日开始，官方公告于 7 月 9 日发布。
FreeBSD 11.3-RELEASE 是 stable/11 分支的第四个发行版，在 11.2-RELEASE 的稳定性和可靠性基础上进一步改进。
此外，我们还启动了 12.1-RELEASE 的准备工作，该发布周期始于 9 月 6 日。12.1-RELEASE 是首个采用“无冻结”方式发布的版本，作为实验，旨在消除开发分支代码冻结的硬性要求。不过，向 releng/12.1 分支提交的变更仍需发行工程团队的明确批准。
目前，该版本已完成三次 BETA 构建，并进行了两次 RC 构建，最终 12.1-RELEASE 构建计划于 11 月 4 日进行。
此外，本季度我们还发布了多个 head 和 stable/11 分支的开发快照，同时也发布了 stable/12 的快照（但不包括 12.1-RELEASE 期间）。
本季度的许多工作由 Rubicon Communications, LLC（Netgate）和 FreeBSD 基金会赞助。
联系人：安全团队 <secteam@FreeBSD.org>
安全团队的多名成员在 10 月的供应商峰会上会面，正式确立了专注于架构和加密工程的团队结构，以补充现有的产品安全事件响应职能。
自 6 月以来，我们开始每两周召开一次电话会议，讨论重要问题，并紧密协作发布安全公告和勘误通知。
2019 年第三季度发布的安全公告（Security Advisories）：7 条
2019 年第三季度发布的勘误通知（Errata Notices）：5 条
涵盖多个领域的项目，从内核和用户空间到 Ports 以及外部项目。
联系人：Ed Maste <emaste@FreeBSD.org>
为了简化创建安装镜像或虚拟机系统镜像的过程，我们需要在 makefs(8) 中支持 FAT 文件系统。Makefs 最初由 NetBSD 开发，FAT 支持也较早在 NetBSD 中加入，但 FreeBSD 迁移该工具时并未包含 FAT 支持。
来自滑铁卢大学的 FreeBSD 基金会实习生 Siva Mahadevan 负责从 NetBSD 迁移 FAT 支持。我对 Siva 的工作进行了重构和更新，并在本季度将其合并到 FreeBSD 代码库。经过一些后续修复，我们现在可以在不使用 md(4) 且无需 root 权限的情况下构建 FAT 文件系统镜像。
该项目由 FreeBSD 基金会赞助。
联系人：Alan Somers <asomers@FreeBSD.org>
FUSE（File system in USErspace，用户空间文件系统）能在用户空间程序实现文件系统。它广泛用于支持 NTFS 等非主线文件系统，也可用于 sshfs 等特殊的伪文件系统。FreeBSD 的 FUSE 驱动最初于 2012 年作为 GSoC 项目引入，但此后基本被忽视。当前的 FUSE 代码存在大量 bug，且已严重过时，相较于主流实现落后约 11 年。
我在 2019 年第三季度完成了该项目，修复了一些新引入的 bug，并修正了长期存在的 sendfile 相关 bug，该 bug 影响 FUSE（Bug 236466）。随后，我将所有改动合并到 head 和 stable/12 分支，并解决了由此产生的 Coverity CIDs（代码缺陷）。截至目前，未收到新的 FUSE 相关 bug 报告，因此我只能假设一切运行良好。如发现问题，请联系 asomers@FreeBSD.org。
该项目由 FreeBSD 基金会赞助。
联系人：编程之夏管理员 <soc-admins@freebsd.org>
FreeBSD 项目很高兴能够参与 2019 年的谷歌编程之夏，这是我们连续第 14 年参与该计划。今年我们有六个成功的项目：
双栈 ping 命令 —— Ján Sučan
防火墙测试套件 —— Ahsan Barkati
内核 Sanitizer —— Costin Carabaș
FreeBSD Jail 的 IP 地址 MAC 策略 —— Shivank Garg
构建 Ports 过程与本地安装的分离 —— Theron Tarigo
虚拟内存压缩 —— Paavo-Einari Kaipila
我们感谢谷歌提供与这些学生合作的机会，并希望他们未来能继续为 FreeBSD 贡献力量。
该项目由谷歌编程之夏赞助。
联系人：Shivank Garg <shivank@FreeBSD.org>
随着 FreeBSD 引入 VNET(9)，Jail 可以自由配置其 IP 地址。然而，出于多种安全原因，宿主机可能需要限制这一权限。本项目利用 mac(9) 访问控制框架，通过 sysctl(8) 让宿主机的 root 用户定义规则，以限制 FreeBSD Jail 的网络访问权限。
该项目开发了一个可动态加载的内核模块（mac_ipacl），基于 TrustedBSD MAC 框架实现了一套网络栈的安全策略。宿主机的 root 用户可以定义策略规则，限制 Jail 内的 root 用户只能使用特定的 IPv4 或 IPv6 地址、子网或网络接口。
宿主机可定义一个或多个 IP 地址/子网列表，供 Jail 选择。
宿主机可限制 Jail 绑定特定的 IP 地址或子网。
宿主机可限制 Jail 仅能使用指定的网络接口。
mac_ipacl 模块是个可加载的内核模块。它在 netinet/in.c 和 netinet6/in6.c 中实现了 MAC 检查，以验证 Jail 请求的 IP 地址。这些检查的实现基于 SIOCAIFADDR（IPv4）和 SIOCAIFADDR_IN6（IPv6）ioctl 处理程序，这些处理程序用于将 IP 地址添加到接口，并被用户空间的 ifconfig 使用。MAC 框架作为 netinet 和 mac_ipacl 模块之间的中介，对比规则后决定是否允许请求的 IP 地址。该模块可通过 sysctl 进行调优，策略规则也可以通过 sysctl 进行配置。
该模块附带了一套集成至 kyua 和 ATF 的测试脚本。
我为该模块编写了一份 man 页面。请参考 mac_ipacl(4) 以了解如何使用该 MAC 模块及相关示例。
可加载的内核模块 - mac_ipacl 在 sys/security/mac_ipacl
ATF 测试套件 - tests/sys/mac/ipacl
该 MAC 模块的 man 页面 - mac_ipacl.4 在 share/man/man4/mac_ipacl.4
该项目是 2019 谷歌编程之夏的一部分，由 Bjoern A. Zeeb <bz@FreeBSD.org> 指导。该模块已完成审查，且代码修订已被接受，即将合入主线，目前等待更多业界用户测试。
如果你愿意尝试该模块，并分享你的使用经验，我将不胜感激。请随时分享你的想法和反馈，并随时通过邮件与我联系。
联系人：Ed Maste <emaste@FreeBSD.org>
FreeBSD 基金会希望确保 FreeBSD 在包括笔记本电脑在内的现代硬件上依然可行。为此，我们计划采购一代及多代 FreeBSD 社区成员青睐的笔记本电脑，评估现有硬件支持情况，并尽可能实现缺失的硬件支持。
作为本项目的第一款测试设备，我们选择了第七代联想 X1 Carbon。
该项目由 FreeBSD 基金会赞助。
联系人： Rick Macklem <rmacklem@freebsd.org>
RFC-7862 描述了 NFS 版本 4 协议的一个新的次要版本。本项目实现了该次要版本。
NFS 版本 4 次要版本 2 协议为 NFS 添加了多个可选功能，例如支持 SEEK_DATA/SEEK_HOLE、在服务器端进行文件复制以避免数据在线传输，以及对 posix_fallocate() 和 posix_fadvise() 的支持。这些功能有望提高某些应用程序的性能。
该实现目前已接近完成，最近的工作主要是测试。已经完成了一轮与 Linux 的互操作性测试。当前仍需要测试的主要部分是 NFSv4.2 在 pNFS 服务器上的使用，预计很快将开始相关测试。待 pNFS 测试完成，我认为该代码即可合并到 FreeBSD head/current。
欢迎大家进行测试。修改后的内核可在 此处 获取，并可在最近的 FreeBSD head/current 系统上运行。客户端挂载时需要使用选项 "minorversion=2" 来启用该协议。
联系人： Ganbold Tsagaankhuu <ganbold@FreeBSD.org>
以下功能已添加，以支持 FreeBSD 上的 RK3399 SoC eMMC：
扩展 simple_mfd 驱动，以便在节点与 syscon 兼容时，暴露 syscon 接口。例如，Rockchip RK3399 的 GRF（通用寄存器文件）既兼容 simple-mfd，又兼容 syscon，并且包含 usb2-phy、emmc-phy 和 pcie-phy 等设备。
使 Rockchip 的 GRF 驱动成为 Simple MFD 驱动的子类。
添加 Rockchip RK3399 eMMC PHY 驱动。
为 Rockchip RK3399 SoC 添加 eMMC 支持代码。
以上所有功能已在 NanoPC-T4 开发板上测试。
联系人：
Andrew Turner <andrew@FreeBSD.org>
Mark Johnston <markj@FreeBSD.org>
Michael Tuexen <tuexen@FreeBSD.org>
Samy Al Bahra <sbahra@freebsd.org>
请参阅 2019 年第一季度报告中的 syzkaller 条目，了解 syzkaller 的介绍。
目前，我们仍在持续修复 syzkaller 发现的漏洞。在过去三个月内，syzkaller 直接发现并促成修复的内核漏洞超过 12 个，并且多个 syzkaller 生成的复现案例已整合进我们的测试套件。
backtrace.io 通过 Samy 提供了一台大型服务器，专门用于运行 syzkaller 以在 bhyve 下对 FreeBSD 进行 fuzzing。虽然谷歌运营的公共 syzkaller 实例（syzbot）已经在 fuzz FreeBSD，但运行多个 syzkaller 实例仍然证明是有益的：不同的实例能发现不同的漏洞。此外，syzkaller.backtrace.io 能让我们尝试 FreeBSD 特定的扩展。目前，该实例会将每次崩溃的数据上传至 backtrace.io，使得崩溃分析和分类变得更加容易。我们计划在不久的将来向 FreeBSD 开发者开放这一服务。
接下来，我们将继续扩展 syzkaller 的覆盖范围，并简化用户和开发者运行私有实例的过程，同时提供可选的内核崩溃信息收集功能，以便调试或提交报告。
该项目由 backtrace.io 和 FreeBSD 基金会赞助。
联系人： D Scott Phillips <scottph@FreeBSD.org>
英特尔已将 TPM2 软件栈的移植版本贡献至 FreeBSD ports 代码库，新增的 ports 包括 security/tpm2-tss、security/tpm2-tools 和 security/tpm2-abrmd。
tpm2-tss 提供了一组库，暴露了符合 TCG TPM 2.0 规范的各种 TPM2 API 以供使用。
tpm2-tools 提供了一组命令行工具，这些工具使用 tpm2-tss 库执行 TPM 相关操作。
tpm2-abrmd 是一个用户空间守护进程，充当 TPM 访问代理和资源管理器，可将多个 TPM 用户复用到同一个 TPM 设备上。
该项目由英特尔公司赞助。
更新了内核子系统/功能、驱动支持、文件系统等内容。
联系人：Konstantin Belousov <kib@FreeBSD.org>
比较并交换（CAS）是硬件辅助的原子读/修改/写操作的基本构建块之一。一些架构直接支持它，例如 x86 和 sparc。其他架构提供不同的构建块，通常是成对的 Load Linked / Store Conditional 指令（ll/sc），可用于构造 CAS 或其他原子操作，如 Fetch-And-Add 或使用普通算术指令执行的任何原子算术操作。AArch64 上的 LDXR/STXR 指令对就是一个例子。
ll/sc 操作的执行方式是，首先使用 load linked 指令从内存加载一个值，并同时将缓存行标记为独占访问。然后使用 store conditional 指令更新该值，但前提是该缓存行未被写入。如果其他 CPU 对该缓存行进行了写入，则 store 指令将失败。因此，ll/sc 架构上的原子操作通常会在 store 失败时重试整个操作，因为这通常只是意味着当前 CPU 竞争失败，甚至可能是偶然失败。这就是所谓的“强”CAS 和原子操作。如果原子操作返回失败，则根据 C 标准，该 CAS 变体称为“弱”CAS。
在 FreeBSD 线程库的锁实现中，当用户空间的快速路径模式不可用时，内核通常需要对用户内存位置执行 CAS 操作。除了 CAS 的所有正常保证外，还必须确保其安全性和对分页的容忍度。在 FreeBSD 中，casueword32(9) 原语为内核提供了对用户模式 32 位字的 CAS 操作。Casueword32(9) 最初实现为强 CAS，与 x86 硬件 CAS 指令的工作模式类似。
使用强实现的 casueword 可能会带来风险，因为相同的地址可能被同一进程或其他进程中的恶意线程访问。如果这样的线程不断地修改 ll/sc 循环使用的缓存行，它可能会导致内核模式线程一直卡在循环中。由于循环很紧密，不会检查信号，因此该线程无法被终止或杀死。
解决方案是使 casueword 实现为“弱”CAS，这意味着原语的接口必须更改，以允许向调用方通知偶发失败。此外，重试的责任现在由调用方承担。
该更改已适用于所有架构。即使在 x86 上，新的 casueword 也直接返回 CMPXCHG 指令后的 PSL.ZF 值。所有大约二十个使用该原语的代码（均位于 kern_umtx.c）都经过检查，并在必要时添加了重试逻辑。
作为一个相关的说明，内核中的 atomic_cmpset(9) 操作是强 CAS，而 atomic_fcmpset(9) 应该是弱 CAS，除非被特定架构破坏。目前的通用态度是，重试应该由调用方负责。
本项目由 FreeBSD 基金会赞助。
联系人：Mark Johnston <markj@FreeBSD.org>
现代 CPU 架构支持将内存映射标记为“不可执行”（NX），防止处理器执行该内存区域的内容。NX 映射是一种重要的安全缓解措施，因为它可以隔离代码和数据，防止攻击者控制的数据被意外执行。W^X（写 XOR 执行）是一种安全策略，禁止同时具有可写和可执行权限的内存映射。根据该策略，所有可修改的内存必须使用 NX 标志映射。这一策略可以降低利用漏洞执行任意代码的风险。
FreeBSD 早已尽可能在用户空间映射中使用 NX 标志，但直到最近几年才开始将其应用于内核映射。最近的一个项目旨在为 amd64 内核实现默认 W^X 策略，具体做法是审查内核中仍然可执行的映射，并进行修改，要么应用 NX 标志，要么使其只读。这项工作已经合并到 HEAD 分支，并将在 FreeBSD 13.0 和 12.2 版本中可用。类似的工作也计划应用于其他 CPU 架构。
为了帮助审计内核映射保护，新增了 sysctl 选项 vm.pmap.kernel_maps ；它可以输出内核页表项及其属性的快照。这样，违反 W^X 政策的映射可以被轻松发现和调查，同时该 sysctl 选项也能为有兴趣研究内核内存布局的用户提供有用信息。
除了极少数情况外，唯一需要执行权限的内核映射应当是内核本身和可加载的内核模块。然而，许多其他内存区域也被错误地映射为可执行，这些问题已被识别并修正。为了解决内核代码映射的问题，amd64 内核的链接脚本被修改，以便将 .text 段填充到 2MB 边界。这样可以保持 .text 段的超级页（superpage）映射优化，同时避免因代码与数据共享 2MB 页面而导致的数据可执行问题，代价是增加了一些内存浪费。
强制 W^X 规则比预期更具挑战性。与 FreeBSD 支持的其他 CPU 架构不同，amd64 内核模块是以可重定位目标文件（.o 文件）进行链接的，而其他架构的内核模块通常是动态共享对象（DSO，即 .so 文件）。.o 文件的使用使得 amd64 内核模块代码更高效，因为 DSO 需要额外的间接寻址开销，而这些开销在内核中是无意义的。在本项目中，我们尝试让 amd64 也使用 DSO 方式，但发现这会强制更改 amd64 内核代码的编译模型，导致额外的性能损失。
使用 .o 文件的主要问题在于，它们的段（section）默认不会按页对齐，而映射保护是在页（4KB）粒度上应用的。这导致段之间的重叠会带来问题，例如 .text 段的末尾可能与 .data 段的起始部分共享同一页。一个可能的解决方案是在加载内核模块时重新排列段并添加填充，但这会破坏 dtrace(1) 和 kgdb 等调试工具，因为它们假定内核链接器不会修改模块的布局。因此，我们为 amd64 内核模块新增了一个链接脚本，以便为特定段添加填充。此外，内核链接器也被修改，以根据段标志限制映射保护。
经过这些修改后，amd64 内核现在能够在启动时完全避免可写且可执行的映射。虽然部分工作是特定于该架构的，但其中许多改进可以推广到其他受支持的架构。
本项目由奈飞赞助。
联系人：李鑫 <delphij@FreeBSD.org> 联系人：Yoshihiro Ota <ota@j.email.ne.jp>
ZLIB 是一款广泛用于各种软件的压缩库。FreeBSD 系统曾使用一个非常古老（超过 20 年）的 zlib 版本（1.0.4），并维护了三个不同的副本：一个在用户态，一个在 ZFS 中，另一个在内核中。Xin 和 Yoshihiro 进行了升级，将 zlib 更新至最新版本并消除了这两个额外的副本。在这一过程中，zlib 版本被升级至 1.2.11，netgraph 的 ppp 代码被重新实现以使用标准 zlib，同时删除了未维护的代码。现在，FreeBSD 代码库中只保留了一个最新版本的 zlib，并在内核中公开了 compress、compress2 和 uncompress API，使得后续 zlib 变更的引入更加简单。
联系人：Brooks Davis <brooks@freebsd.org>
类 Unix 系统提供 mmap(2) 系统调用，用于分配内存或将文件、设备映射到内存，并允许指定访问保护权限；mprotect(2) 系统调用用于更改已映射内存的保护权限。保护标志指定内存是否可读、可写和/或可执行（分别对应 PROT_READ、PROT_WRITE 和 PROT_EXEC）。传统上，mprotect(2) 可用于设置任何所需的权限（除了共享映射的文件如果是以只读方式打开的，则不能设置 PROT_WRITE）。
一个新的宏 PROT_MAX() 可指定 mmap(2) 和 mprotect(2) 调用的最大可能保护标志。程序可以通过该功能指定映射是否可以在未来更改以允许特定访问权限。例如，可以创建一个映射，使其可以被设置为可读和可写，但永远不能变为可执行。
最大保护值通过 PROT_MAX() 宏提供，并与常规保护值进行 OR 运算。
这一更改使得，例如，在运行时链接或 JIT 代码生成期间必须可写的区域，在写入完成后可以被永久设置为只读 + 可执行。这与其他操作系统提供的 Write-XOR-Execute (W^X) 保护互补，使程序员可以更精确地控制内存权限。
例如，请求一块永远不能变为可执行的内存：
请求一块初始不可执行，但可以在之后被赋予执行权限的内存：
此更改调整了 mprotect 的参数检查逻辑，并在检测到未处理的保护标志时返回错误。这与 POSIX 标准有所不同（POSIX 仅规定如果无法设置有效权限才会返回错误），但这与 Linux 的行为一致，并更接近于历史上的 mmap 行为。
除了显式设置最大权限外，还引入了一个实验性 sysctl 变量 vm.imply_prot_max。当该变量设置为 1 时，mmap 会假定请求的初始权限就是最大权限。然而，这种行为会破坏某些代码，例如，使用 PROT_NONE 预留内存空间，然后在部分区域映射内容的代码。因此，未来版本可能会提供按二进制文件或进程进行选择加入/退出的选项，而当前形式的 sysctl 可能会被移除，因此未被正式记录。
尽管这些标志是非可移植的，但可以通过简单的 #ifdef 结构在可移植代码中使用，例如：
赞助商：美国国防高级研究计划局、美国空军研究实验室
联系人：Konstantin Belousov <kib@FreeBSD.org>
在 ASLR 这一极具实用价值的补充功能之后，接下来要实现的流行安全特性就是栈地址随机化。
在 FreeBSD 上，主用户空间线程的栈传统上是从用户地址空间的顶部分配，并向下增长。除了用户空间入口时的初始栈指针，这一区域还包含程序参数和环境变量（即所谓的 strings），以及 ELF 镜像的辅助向量数据。
考虑到要随机化 strings 和主线程初始帧的地址，在地址空间中移动主栈区域并不可行。这会导致严重的 ABI 破坏，使许多已经编码的内省工具失效，并会不必要地增加用户地址空间的碎片化。
因此，我们采用了更常见的方法，即在栈顶和 strings 存放位置之间添加一个大小随机的间隙，并确保符合栈对齐要求。栈间隙仅在 ASLR 启用时生效（默认未启用），并且栈间隙本身也是启用的（如果 ASLR 启用，则默认启用）。栈间隙的最大大小由栈总大小的百分比决定。
然而，这种间隙方法的主要缺点很快就显现出来了。由于间隙是从正常栈区域中切割出来的，因此如果程序使用 rlimit(RLIMIT_STACK) 来缩小栈大小，而新限制小于间隙大小，就可能会截断活动栈区域。例如，在 amd64 平台上，默认的主线程栈大小为 512MB，即使最大间隙只有 1%，也会浪费约 5MB 的栈空间，从而可能导致限制调整失败。
使用 rlimit(2) 这样操作的常见原因之一是，一些程序使用 mlockall(2) 锁定整个地址空间，为了避免超过 RLIMIT_MEMLOCK，它们尝试减少可能被锁定的栈大小。
第一个因该问题受影响的程序是 ntpd，它在启动后会将栈大小重设为一个非常小的值。目前，我们已经从 ntpd 中移除了地址空间锁定功能，因为事实证明，这对时间同步性能没有任何实质性帮助，尽管这一做法曾被广泛认为有用。
我个人认为，这个问题更多地是由于用户接口的不便，而不是栈间隙方法本身的问题。我们应该提供更简单的方式来指定较小的栈间隙，而不仅仅是使用整数百分比来调整。但目前我还没有找到令人满意的解决方案，且在修复 ntpd 之后，该问题的严重性似乎已大幅降低，因此尚未深入研究。
本项目由 FreeBSD 基金会赞助。
联系人：Konstantin Belousov <kib@FreeBSD.org>
由于架构设计的需要，页面错误的处理被分成了两个部分。第一部分是与架构相关的低级机器异常处理程序，而第二部分是架构无关的 vm_fault() 函数，位于 sys/vm/vm_fault.c 文件中。
与页面错误处理相关的机器依赖代码通常由三个组件组成：
由汇编语言编写的跳板（trampoline），用于创建 C 语言的执行环境，并收集硬件提供的页面错误信息；
trap() 函数，作为 C 级通用入口点，用于分发所有异常处理；
trap_pfault() C 函数，专门用于处理页面错误。当需要 VM 提供帮助以解决问题时，trap_pfault() 会调用 vm_fault()。
如果页面错误由 trap()/trap_pfault() 或 vm_fault() 处理成功，则故障指令会被重新执行。如果无法处理，下一步的操作取决于故障发生的模式：
如果是在内核模式下，并且内核已安装了辅助处理程序，则调用该处理程序，而不是返回到故障指令处。
否则，发生在内核模式下的页面错误会导致系统 panic。
如果未处理的页面错误发生在用户模式下，所有 Unix 系统都会向导致异常的线程发送信号。POSIX（或单一 Unix 规范）列出了应发送信号的几种情况，并规定了必须提供的信号编号和 siginfo 中的 si_code。
不幸的是，FreeBSD 在这方面的兼容性一直较差。很久以前，为了提高兼容性，我们更改了访问权限不匹配的页面错误所发送的信号。然而，这导致了多个基于垃圾回收（GC）的运行时系统出现问题，因为它们已根据 FreeBSD 之前的行为进行了特定的调整。因此，我们引入了 sysctl 选项 machdep.prot_fault_translation，以允许用户控制该行为。但最近又发现了更多的兼容性问题。
问题的部分原因在于，计算信号和 si_code 的逻辑位于 trap_pfault() 之中。换句话说，每个架构都各自实现了这一逻辑，并且往往包含一系列特定的 bug 和非标准行为。有时，代码甚至会错误地将 vm_fault() 返回的 Mach 错误解释为 errno。
为了解决这个问题，我们新增了 vm_fault_trap() 辅助函数，专门用于处理 trap() 入口的页面错误。它的功能包括：
生成页面错误的 ktrace 事件；
调用 vm_fault() 进行错误处理；
解释 vm_fault() 的返回值，转化为用户可见的错误条件，并返回计算后的信号编号和 si_code。
这样，trap_pfault() 只需要处理真正与架构相关的错误。例如，在 amd64 平台上，某些情况下会因为访问受保护的内存区域（protection key violation）而触发错误。
除了提高标准兼容性并修复 bug 之外，我们还对用户空间提供了更精细的错误信息。例如，当 SIGBUS 由写时复制（copy-on-write）失败导致，并且原因是超出了 swap 预留限制时，我们现在会提供特定的 si_code，即 BUS_OOMERR。
本项目由 FreeBSD 基金会赞助。
更新平台特定功能并引入对新硬件平台的支持。
联系人：Michal Stanek <mst@semihalf.com>
联系人：Kornel Duleba <mindal@semihalf.com>
联系人：Marcin Wojtas <mw@semihalf.com>
Semihalf 团队继续推进 FreeBSD 对 Broadcom BCM5871X SoC 系列 的支持。
BCM5871X 是基于 64 位 ARMv8 Cortex-A57 的四核通信处理器，主要面向 10G 路由器、网关、控制平面处理和 NAS 等网络应用。
自上次更新以来已完成的工作：
iProc PCIe 根复合体（内部和外部总线）：修复与改进，
用于 IPsec 卸载的加密引擎加速。
待办事项
上游合并工作。预计将在 2019 年第四季度提交/合并至 HEAD。
本项目由 Juniper Networks, Inc. 赞助。
联系人：Robert Watson <rwatson@FreeBSD.org>
联系人：Andrew Turner <andrew@FreeBSD.org>
联系人：Brooks Davis <brooks@FreeBSD.org>
2019 年 9 月，Arm 宣布了 Morello——一种实验性的多核超标量 ARMv8-A CPU、SoC 和原型开发板，并扩展实现了 CHERI 保护模型。Morello 预计将于 2021 年发布。更多详细信息可参见 Arm 官方博客、Light Blue Touchpaper 博客，以及 CHERI 官网。
我们已更新 CheriBSD（一个最初面向基于 MIPS 的 SRI/Cambridge CHERI 处理器原型的 CHERI 适配 FreeBSD 版本）以支持当前的架构草案。这包括完整的用户空间 CHERIABI CheriABI 内存安全特性，同时也提供向后兼容性，以运行现有的 ARMv8-A 用户空间二进制文件。
我们将继续更新 CheriBSD/Morello 以适配最终确定的 ISA，同时紧密跟踪公开的 CheriBSD/MIPS 主分支，以获取成熟的 CHERI 相关软件功能，并同步 FreeBSD 主干开发分支的变更。
我们预计将在 2020 年 ISA 和工具链发布后，将 CheriBSD/Morello 作为开源项目公开。
本项目由 DARPA 和 AFRL 赞助。
联系人：Mark Linimon（ports）<linimon@FreeBSD.org> 联系人：Justin Hibbits（src）<jhibbits@FreeBSD.org> 联系人：Piotr Kubaj（ports）<pkubaj@FreeBSD.org>
FreeBSD/powerpc 项目取得了重大进展。然而，正如我们在 BSDCan 2019 上发现的，我们并未很好地向外界宣传这些进展。
关键点：
在最近的硬件上，powerpc64 的 src 代码已达到生产级别质量超过一年。
powerpc64 的 ports 代码已达到开发者级别质量超过 18 个月。
主要目标平台：
IBM POWER8 和 POWER9 处理器上的 powerpc64（目前最新的可用硬件）。这是未来的主要开发方向。FreeBSD 12 是最低要求，建议使用 FreeBSD 13。
旧款 Apple Power Mac 上的 powerpc64，作为持续但次要的支持方向。任何 FreeBSD 版本均应可运行。
x5000 上的 powerpc64，但目前仍处于开发者级别质量。建议使用 FreeBSD 13。
Amiga A1222 上的 powerpcspe，但目前仍处于开发者级别质量。建议使用 FreeBSD 13。
软件状态：
powerpc*/12 及更早版本仍然使用 base 中的旧版 gcc 4.2.1。
powerpc*/13 即将切换到 base 中的 llvm90。我们已经投入了大量工作，以尽量减少回归问题。待切换完成（请参考上方 llvm-elfv2 相关链接），powerpc*/13 对 gcc 4.2.1 的支持将不再是优先事项。
FreeBSD.org 提供了 powerpc64/12（季度更新）和 powerpc64/13（默认）的软件包集，可通过常规方法获取。
Firefox 在 powerpc64 上可运行，尽管需要使用尚未提交的实验性补丁。
截至最近一次 powerpc64/13（仍基于 gcc 4.2.1）构建的软件包统计如下：
33306
30514
245
1686
861
每天都在提交更多 ports 相关修复。
此外，Piotr 感谢 FreeBSD 基金会赞助他的个人 Talos 服务器，以及 Raptor（通过其 IntegriCloud 子公司）借出的服务器，支持 talos.anongoth.pl 的运行。
团队还感谢 IBM 借出的两台 POWER8 服务器，以及俄勒冈州立大学（OSU）提供的托管服务。同时，我们也要感谢 clusteradm 团队，他们负责维护托管在 NYI 的 Tyan POWER8 服务器的在线运行。
联系人：Marcin Wojtas <mw@semihalf.com> 联系人：Artur Rojek <ar@semihalf.com>
Semihalf 团队已开始为 NXP LS1046A SoC 提供 FreeBSD 支持。
LS1046A 是一款四核 64 位 ARMv8 Cortex-A72 处理器，集成了数据包处理加速功能，并支持 10 Gb 以太网、PCIe 3.0、SATA 3.0 和 USB 3.0 等高速外设，适用于广泛的网络、存储、安全和工业应用。
自上次更新以来已完成的工作：
DPAA 网络接口支持
SD/MMC
USB 3.0
I2C
GPIO
正在进行的工作：
QSPI
网络性能优化
待办事项
将已开发的功能合并到上游。这项工作预计将在 2019 年第四季度提交并合并到 HEAD 分支。
本项目由 Alstom Group 赞助。
影响基本系统及其内置程序的修改。
联系人：Ed Maste <emaste@FreeBSD.org>
gets 是一个用于从标准输入读取字符串的 C 库函数，已被废弃。由于无法安全使用，它在 C11 标准中被移除。受 Paul Vixie 在 vBSDCon 2017 演讲中的评论启发，我开始研究如何从 libc 中删除 gets。
相关补丁 已在 Phabricator 上多次优化，portmgr 团队还进行了多次 实验性构建，以找出受影响的 Port。为了保持对现有使用 gets 的软件的二进制兼容性，采用了符号版本控制。
该更改已于 2019 年 9 月 提交，并将在 FreeBSD 13.0 中生效。
本项目由 FreeBSD 基金会赞助。
影响 Ports 的更改，无论是涉及大多数树形结构的广泛更改，还是个别 Port本身的更改。
联系人：Dan Langille <dvl@FreeBSD.org>
FreshPorts 将提交合并为易于跟踪的格式，方便你跟踪最喜爱的 Port 的更改。它还处理 src、doc 和 www 提交。FreshPorts 会解析传入的电子邮件并刷新数据库中的数据。
9 月初，我开始研究 FreshPorts 如何使用 Git 仓库处理提交。结果是 一种方法 来识别新提交并进行遍历。
接下来的想法是 提交钩子，但这一过程中最有趣的部分是提交遍历。
在 EuroBSDCon 2019 FreeBSD 开发者峰会上，我写了一个小的需求部分，并且得到了两方的大力帮助：
Jan-Piet MENS 推荐了一个 Python 库，结果非常棒
Sergey Kozlov 编写了使用该 Python 库创建 XML 的 Python 代码
在回家的路上，我成功让代码将 Git 提交解析为 XML，并加载到 FreshPorts 数据库中。
从会议回到家后，我为基于 Git 的处理创建了一个新的 FreshPorts 实例。该网站与 Git 无关的部分没有任何更改。
剩余的任务：
自动化脚本（git pull 等）
检测新提交（以便后续遍历）
设计一个轻量级的 Git 钩子
事件：EuroBSDCon 2019 黑客松 由 Intel Corporation 赞助（Sergey Kozlov 完成的工作）
联系人：Greg Lewis <glewis@FreeBSD.org>
在过去几个季度中，已经进行了大量的工作以改进对 Java 11 及更高版本的支持，并且一些工作已回溯到 Java 8。
自 3 月首次发布 amd64 版本以来，FreeBSD 支持已经添加了一些功能，例如：
Java Flight Recorder
HotSpot 服务代理
HotSpot 调试器
DTrace
Javac 服务器
Java Sound
SCTP
此外，还为 aarch64、i386 和 powerpc64 架构添加了支持。
大多数功能已支持后，重点转向合规性，并使用内部 JDK 测试套件作为衡量标准。第三季度的主要工作集中在此，测试失败从 50 多个减少到仅 2 个 tier1 测试失败（这些似乎完全不影响功能）。一些重要的修复包括：
堆栈溢出崩溃
外部进程处理错误
unpack200 工具（在小端系统上）
HotSpot 调试器功能，例如线程枚举
网络功能
最后，这项工作已向前移植到 Java 12 和 13，FreeBSD 在这些版本发布的当天或之后就支持它们。
请注意，这项工作是与许多其他人合作完成的。尽管有太多贡献者无法一一列出（请查看 GitHub 仓库的提交历史），我特别想感谢 OpenBSD 的 Kurt Miller，他多年来为 BSD 上的 Java 做出了不懈的努力。
我还要感谢 FreeBSD 基金会的赞助，使我能够专注于第三季度的这项工作。
本项目由 FreeBSD 基金会赞助。
联系人：Adriaan de Groot <kde@FreeBSD.org>
FreeBSD 上的 KDE 项目为 FreeBSD 打包了 KDE 社区生产的软件。这些软件包括完整的桌面环境、艺术应用程序 https://kdenlive.org 和数百个可以在任何 FreeBSD 桌面计算机上使用的其他应用程序。
除了 KDE 本身，团队还维护 Qt 库、CMake 构建系统和一些其他在 KDE 堆栈中使用的 C++ 库。
KDE 上游每月发布 KDE Frameworks（库），每季度发布 KDE Plasma（桌面环境），每年发布两次 KDE 应用程序（适用于所有平台）。 FreeBSD KDE 团队追踪了这些组件的十二个更新，确保 FreeBSD 始终是最现代的系统之一，使用最新的 KDE 软件（和 Qt）。
随着 KDE 的 Digikam 6.3.0 发布，出现了一个大型（可能会破坏现有功能，仍需更多调查）更改，它停止使用之前的插件系统（“旧”插件仍然被其他 KDE 软件使用）。
新增了一个名为 Ruqola 的即时通讯客户端，它是一个基于 Rocket.chat 的富文本即时通讯工具。
CMake 更新了两次。这迫使重新构建了数千个基于 C++ 的 Port。KDE on FreeBSD 团队然后修复这些 Port，无论错误是在 CMake 更新中，还是在上游代码中。这些更新往往需要大量的工作，因为它们涉及不熟悉的（而且常常非常老旧的）代码。
公开的错误列表 本季度增加到 24 个。随着新问题的出现和旧问题的解决，它通常保持在 20 个左右。我们欢迎详细的错误报告和补丁。KDE 软件包更新在 GitHub 上的 Ports 仓库副本 中准备，然后合并到 SVN 中。我们也欢迎在此提交拉取请求。
联系人：René Ladan <portmgr-secretary@FreeBSD.org>
联系人：FreeBSD Ports 管理团队 <portmgr@FreeBSD.org>
FreeBSD Ports 管理团队负责监督 Ports 及其提交者，报告在 2019Q3 期间发生的以下事件：
在过去的一个季度中，Port 数量增长至接近 38,000 个。我们目前有超过 2,000 个未处理的 Port PR，其中 400 个没有分配处理者。在这一期间，169 名提交者对 HEAD 分支提交了 7,340 次更新，对季度分支提交了 561 次更新。这表明上个季度活动增加的趋势仍在持续。
在过去的一个季度中，我们欢迎了 Santhosh Raju (fox@) 和 Dmitri Goutnik (dmgk@) 加入团队，并向 gabor@ 告别。在此期间，feld@ 决定辞去 portmgr@ 和 ports-secteam@ 团队成员职务。我们对他们过去的贡献表示感谢。
在过去的三个月里，bapt@ 戴上工程师帽子，发布了 pkg (1.12) 的新版本，向 Ports 添加了对覆盖层的支持，修复了两个 Make 目标（deinstall-depends 和 reinstall），并清理了 bsd.sites.mk。
在基础设施方面，已废弃并移除了 USES=pure；新增了两个 USES：xorg 和 xorg-cat，取代了旧的 bsd.xorg.mk。同时新增了两个关键词，ldconfig 和 ldconfig-linux，以简化包列表的格式。
一些默认版本发生了变化：Lazarus 更新为 2.0.4，Linux 更新为 CentOS 7，LLVM 更新为 9.0，Perl 更新为 5.30，PostgreSQL 更新为 11，Ruby 更新为 2.6。大部分用户显著可见的 Port 也进行了更新：Firefox 更新为 69.0.1，Firefox-esr 更新为 68.1.0，Chromium 更新为 76.0.3809.132，Xfce 更新为 4.14。
在过去的一个季度中，antoine@ 进行了 48 次实验运行（exp-runs），测试了包更新、更新 bsd.java.mk、测试新的 ldconfig 和 ldconfig-linux 关键词、默认版本更新、新的 xorg 和 xorg-cat USES、基础更新以及 Go 和 Ruby 的各种改进。
联系人：Guido Falsi <xfce@FreeBSD.org>
9月19日，XFCE 桌面环境的 Port 已更新为最近发布的 XFCE 4.14 版本。
这些更新包括将所有主要的 XFCE 组件升级到最新版本，并迁移到 GTK3，只有少数例外。基础组件仍然需要并链接到 GTK2，以支持旧的 GTK2 XFCE 应用程序，例如面板插件。
由于这一变化，gtk-xfce-engine 主题被弃用，因为它仅支持 GTK2。XFCE 的元包默认安装 greybird 主题，但默认情况下未启用。
此新版本还包括了自己的 xfce4-screensaver 程序，默认安装。
最后，XFCE 所依赖的默认显示管理器已更改为 LightDM。
在 Bugzilla 中报告了几个回归问题。特别是，大多数用户遇到的是窗口管理器的回归问题：在特定的图形显示硬件上，窗口管理器未能正确绘制窗口装饰，导致在受影响的系统上窗口装饰显示为黑色且粗糙。
该问题已在上游的 bug 跟踪系统中报告，目前正在寻找解决方案。
如果有人遇到这个显示问题，并且能够进行测试，请联系 xfce@freebsd.org，帮助寻找解决方案。
许多项目建立在 FreeBSD 上，或将 FreeBSD 组件纳入其项目中。由于这些项目可能对更广泛的 FreeBSD 社区感兴趣，我们有时会在季度报告中包含这些项目提交的简要更新。FreeBSD 项目不对这些提交中的任何声明的准确性或真实性做出任何表示。
联系人：Oleg Ginzburg <olevole@olevole.ru>
ClonOS 是一个基于 FreeBSD 和 CBSD 框架的交钥匙开源平台。ClonOS 提供一个完整的 Web UI，方便控制、部署和管理 FreeBSD jail 容器及 bhyve/Xen 虚拟环境。
ClonOS 目前是唯一支持 Xen 和 bhyve 超级虚拟机在同一主机上共存的平台。由于 ClonOS 基于 FreeBSD 平台，它可以本地创建和管理 jail，让你在不损失性能的情况下运行 FreeBSD 应用程序。
新增对 cloud-init（Linux/BSD 虚拟机）和 cloudbase-init（Windows 虚拟机）的支持，使 FreeBSD 能作为 IaaS 平台，快速部署和使用基于 bhyve 超级虚拟机的虚拟机。
项目开始使用自有的云镜像，以提高稳定性和弹性。
增加了法国、美国和加拿大的镜像站点，以分发 ISO/cloud-init 镜像，除了俄罗斯、拉脱维亚和乌克兰的镜像。
现在我们使用 Jenkins CI 来测试常规 ClonOS 构建：更新 ClonOS 包（感谢 Daniel Shafer）
新的 pkg 仓库已部署，支持通过包安装 ClonOS（目前仅有 FreeBSD-12 包可用）ClonOS 包仓库（感谢 Daniel Shafer）
待处理问题和任务：
迫切需要志愿者、贡献者和测试人员来分发 ClonOS 到 FreeBSD 环境中。
我们希望地理上扩展镜像站点的数量，你的帮助和贡献将不胜感激。
我们迫切寻找托管赞助，以支持各种开发和测试活动。
联系人：Michal Krawczyk <mk@semihalf.com>
联系人：Maciej Bielski <mba@semihalf.com>
联系人：Marcin Wojtas <mw@semihalf.com>
ENA（Elastic Network Adapter）是亚马逊网络服务（AWS）虚拟化环境中的智能网卡。ENA 驱动程序支持多个传输和接收队列，并能处理高达 100 Gb/s 的网络流量，具体取决于所使用的实例类型。
正在为 FreeBSD 开发 ENAv2 驱动程序，类似于 Linux 和 DPDK。在上次更新后，已对补丁进行了内部审核和改进，并在多个 AWS 实例上进行了验证。
自上次更新以来已完成的工作：
验证和审查了 NETMAP 支持
在 A1 实例上将内存映射为 WC，以启用 LLQ 模式
待办事项
向上游提交 NETMAP 支持
向上游提交 A1 实例上 LLQ 模式的修复
联系人：Luca Pizzamiglio <pizzamig@FreeBSD.org> 联系人：Esteban Barrios <esteban.barrios@trivago.com>
一个实验项目已经启动，旨在提供基于 nomad 和 jail 框架 pot 的 jail 编排，类似于 Docker 的编排方式。
这种模型能让我们将 jail 创建和 jail 部署分开。可以使用 pot 框架创建和导出 jail 镜像。然后，使用 nomad 进行部署和编排。我们开发了一个驱动程序，允许 nomad 与 pot 交互。
该项目的目标之一是将非持久性 jail 用作容器，允许我们：
定义类似于 Docker 的容器（但不完全相同，因为底层操作系统不同）
识别 FreeBSD 中可能缺少的功能，以支持这种计算模型
在下一个季度，我们将推出基于该项目的第一个服务。
接下来的步骤包括：
提供更多指南和操作手册
提高稳定性，扩展测试套件
改进工具，创建/管理镜像
该项目由 trivago N.V. 赞助。
联系人：Alfonso Sabato Siciliano <alfonso.siciliano@email.com>
FreeBSD 内核维护一个管理信息库（MIB），其中每个组件（对象）代表系统的一个参数。sysctl 系统调用通过对象标识符（OID）探索 MIB，查找对象并调用其处理程序以获取或设置参数的值。通常，我们需要查找一个对象，不是为了调用其处理程序，而是为了获取其信息（描述、类型、名称、下一个对象等），因此内核提供了一个未公开的接口，该接口在 kern_sysctl.c 中实现。
sysctlinfo 是一个新接口，用于探索 sysctl MIB 并将对象的信息传递到用户空间。该项目提供：README、手册、辅助宏、示例、测试和转换工具。
主要来说，sysctlinfo 提供了一组新的 sysctl 节点（对应于内核接口），以处理最多到 CTL_MAXNAME 层级的对象：sysctl.entryfakename、sysctl.entrydesc、sysctl.entrylabel、sysctl.entrykind、sysctl.entryfmt 和 sysctl.entrynextleaf。此外，还实现了新特性：支持能力模式、sysctl.entryname、sysctl.entryidbyname 和 sysctl.entrynextnode。为了获取关于一个对象的所有信息，内核需要多次查找它，因此编写了新的 sysctl.entryallinfo* 节点，它们比传统方法高效 30%。最后，添加了 byname 节点：它们通过名称查找对象，避免调用 sysctl.name2oid（或类似方法）来探索 MIB 以查找对应的 OID。
sysctlinfo 可以通过 sysutils/sysctlinfo-kmod 安装，或者通过应用 sysctlinfo.diff 补丁进行安装（比模块更高效，因为使用了共享锁）。该接口被 deskutils/sysctlview 1.5、sysutils/nsysctl 1.2 和转换版的 sysctl(8)、sysctlbyname(3)、sysctlnametomib(3) 使用，应该用来获取一个对象的值，适用于 23/24 层级，或者如果某个层级名称仅包含 0 字符。在未来，将添加一个新的 byname 节点，以允许 sysctlbyname() 管理具有非 NULL 处理程序的 CTLTYPE_NODE，例如 sysctlbyname(kern.proc.pid.<pid>)。