FreeBSD Status Report Third Quarter 2026

Contact: FreeBSD Core Team <core@FreeBSD.org>

The FreeBSD Core Team is the governing body of FreeBSD.

Links:
FreeBSD Foundation URL: https://freebsdfoundation.org/
Technology Roadmap URL: https://freebsdfoundation.org/blog/technology-roadmap/
Donate URL: https://freebsdfoundation.org/donate/
Foundation Partnership Program URL: https://freebsdfoundation.org/our-donors/freebsd-foundation-partnership-program/
FreeBSD Journal URL: https://freebsdfoundation.org/journal/
Foundation Events URL: https://freebsdfoundation.org/our-work/events/

Contact: Deb Goodkin <deb@FreeBSDFoundation.org>

The FreeBSD Foundation is a 501(c)(3) non-profit dedicated to advancing FreeBSD through both technical and non-technical support. Funded entirely by donations, the Foundation supports software development, infrastructure, security, and collaboration efforts; organizes events and developer summits; provides educational resources; and represents the FreeBSD Project in legal matters.

Links:
FreeBSD 14.5-RELEASE announcement URL: https://www.freebsd.org/releases/14.5R/announce/
FreeBSD 15.2-RELEASE schedule URL: https://www.freebsd.org/releases/15.2R/schedule/
FreeBSD releases URL: https://download.freebsd.org/releases/ISO-IMAGES/
FreeBSD development snapshots URL: https://download.freebsd.org/snapshots/ISO-IMAGES/

Contact: FreeBSD Release Engineering Team <re@FreeBSD.org>

The FreeBSD Release Engineering Team is responsible for setting and publishing release schedules for official project releases of FreeBSD, announcing code freezes and maintaining the respective branches, among other things.

The Team managed 14.5-RELEASE, leading to the official RELEASE build and announcement in September. Planning has started for the upcoming 15.2-RELEASE, which is due to arrive in December.

The Release Engineering Team continued providing weekly development snapshot builds for the main, stable/15, and stable/14 branches.

Links:
Cluster Administration Team members URL: https://www.freebsd.org/administration/#t-clusteradm

Contact: Cluster Administration Team <clusteradm@FreeBSD.org>
Contact: Philip Paeps <philip@FreeBSD.org>

FreeBSD Cluster Administration Team members are responsible for managing the machines the Project relies on to synchronize its distributed work and communications.

In this quarter, the team has worked on the following:

Links:
FreeBSD Bugzilla URL: https://bugs.freebsd.org/
Total Open Bugs Over Time URL: https://bugs.freebsd.org/bugzilla/page.cgi?id=showreport.html&type=total_open_bugs_over_time

Contact: Bugmeister <bugmeister@FreeBSD.org>

Links:
Alpha-Omega — Linux Foundation Project URL: https://alpha-omega.dev
FreeBSD Foundation URL: https://freebsdfoundation.org
FreeBSD Security Information URL: https://www.freebsd.org/security/

Contact: Pierre Pronchery <pierre@freebsdfoundation.org>

This is my second quarter in the FreeBSD Foundation as part of Alpha-Omega’s Security Engineers In Residence (SEIRs) initiative. Thanks to the input received from the Security Team, I have integrated a staging instance of Forgejo with a self-hosted LLM, demonstrating the potential of new capabilities for the Security Team, without breaching any confidentiality requirements. This system is capable of dealing with incoming security vulnerability reports, by:

This is implemented like a typical, modern CI/CD system with Forgejo’s runner tool as a GitHub-compatible workflow. The aim is to leverage LLM capabilities for our processes, in accordance with the current workflow, without compromising on confidentiality nor on the necessity for quality review by us mortal members of the security team.

Significant polishing is still required, but the corresponding instance in production should be useful even without the LLM part. The automation of the more repetitive tasks of the workflow is expected to help us deal with the steady amount of incoming reports, and to extend capabilities from our individual minds into the team as a whole.

In parallel, I have not spared my efforts towards compliance with the European Cyber Resilience Act (CRA) for the FreeBSD Project. After importing pkgconf in FreeBSD’s base system during the last quarter, I went through a number of iterations for the framework generating Software Bill of Material (SBOM) artefacts during the build. Prepared together with Tuukka Pasanen, the framework is available for review in D56474 and I now believe it to be a serious candidate for integration. I would like to thank everyone who has been providing feedback already! This has helped tremendously to find a balance that feels more right than at any time earlier — at least to me. A separate request for review for the meta-data is now available as well, D60352, which currently generates a total of 218 artefacts for an amd64 build. The balance consists of about one artefact per base package generated, as well as one artefact per library actually used during the build. This way, the complete chain of dependencies can be tracked, while keeping the granularity close to individual third-party projects or internal components.

I would also like to extend my thanks to Alice Sowerby and to Peter Hansteen for an awesome workshop about CRA compliance during EuroBSDCon 2026 in Brussels, this past September 2026. If you have missed it, you may be in luck, as we are gearing up to deliver it again at a future event. Do not hesitate to reach out to us if you are interested, together with your rough location and flexibility for travel, so we can have a more accurate impression of the times and places we should aim for.

Sponsor: Alpha-Omega, The FreeBSD Foundation

Links:
Cyber Resilience Act Readiness URL: https://github.com/FreeBSDFoundation/all-projects/tree/main/Cyber%20Resilience%20Act%20Readiness

The Foundation is running a project through 2026 to actively prepare the FreeBSD Foundation, Project, and community for the EU Cyber Resilience Act. There are six main areas of focus: Security and Vulnerability Handling, SBOM Toolchain, Public Documentation, Community Legislative Engagement, Public Project Repository, and Communications.

Over Q3, the project has continued to move from planning into implementation, with particular focus on readiness for the CRA’s vulnerability and incident reporting requirements that came into force for manufacturers on September 11, 2026.

The Foundation has created a cyber security policy and CRA reporting protocol to support the Foundation in meeting its obligations as an open source software steward. Both have been developed with input from the FreeBSD Core and Security Teams and document how the Foundation will work with the Project and respond if CRA reporting obligations are triggered for the Foundation as a steward. Note that the European Commission has clarified that reporting obligations for stewards begin on December 11, 2027. These documents will remain internal resources for the time being.

Technical work on the Software Bill of Materials (SBOM) toolchain has continued through development, testing, and review. The proposed approach for generating SBOMs for the FreeBSD base system is being refined in response to feedback and still requires further review and supporting changes before integration. Work is also progressing across the wider SBOM ecosystem, both through the Foundation and in the community, including planned support for ports, SPDX-compatible license information, and CycloneDX and SPDX SBOM support in pkgconf.

Public CRA guidance is now available on the FreeBSD Foundation website, providing an overview of the legislation alongside dedicated guidance for FreeBSD business users and community members. This gives FreeBSD users clearer information about how the CRA may affect them, where their responsibilities may sit, and how to work with FreeBSD in meeting their CRA obligations.

The Foundation has continued to engage with the FreeBSD and wider open source communities, especially the Eclipse Foundation’s Open Regulatory Compliance (ORC) working group. At EuroBSDCon 2026, we collaborated with Peter Hansteen to run a day-long CRA and SBOM tutorial. We also presented an update on this project at the FreeBSD Developer Summit.

Project updates and meeting notes continue to be published through the public project repository. As we move into Q4, the focus will be on progressing the SBOM implementation and upstream work, improving the discoverability of our public CRA guidance, and working with the FreeBSD Project to identify key manufacturer needs that relate to their CRA obligation to adopt a secure software lifecycle by December 11, 2027.

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

Open upstream SPDX license identifier PRs:
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

Contact: Tuukka Pasanen <tuukka.pasanen@ilmi.fi>

The FreeBSD Software Bill of Materials (SBOM) effort has been continued during Q3 2026. At last, getting SBOM into FreeBSD source is manifesting itself and hopefully will be finalized in Q4. Thanks to Pierre Pronchery, there is a Phabricator review ongoing: D60352 for FreeBSD source. Also, ports have one for reviewing: D60441 made by Mathieu Arnold.

As an option for SBOM output, there are currently available SPDX 2.2 and Lite 3.0.1. CycloneDX SBOM tool is in work in progress and still needs some love to be as qualified as the output for SPDX. In the future, all SBOM outputs will be under one tool, which will be named sbomtool, and as both solutions rely on pkgconf, they will have CycloneDX when it lands in FreeBSD source.

Additionally, several new SPDX License Identifiers have been accepted. All three are in FreeBSD source: * BSD-2-Clause-pos-unchanged * BSD-Source-Code-no-disclaimer * BSD-Source-alt-GPL

There are several updates from BSD-2-Clause to BSD-Source-beginning-file in review:

Additionally, many third-party repositories have received SPDX License Identifiers, such as libxo (thanks to Juniper for that), and others. Some projects do not want headers, and some are still in active development.

If you want to help with this effort:

Sponsor: FreeBSD Foundation

Links:
fts(3) manual page URL: https://man.freebsd.org/cgi/man.cgi?fts(3)

Contact: Jitendra Bhati <jitendrabhati2026@gmail.com>
Contact: Alan Somers <asomers@FreeBSD.org>

The fts(3) directory traversal library, used by find(1), rm(1), ls(1), chflags(1) and other utilities, historically relied on path-based syscalls that fail in capsicum(4) capability mode.

This quarter fts gained a new fts_openat() entry point that accepts a pre-opened directory descriptor, a per-entry fts_dirfd field, and a conversion of its internals to fd-relative operations, with ABI compatibility preserved through ELF symbol versioning. A traversal can now run entirely inside a Capsicum sandbox.

As a first consumer, chflags was capsicumized to perform its work through chflagsat() on descriptors opened before entering capability mode, confining it to the hierarchies named on its command line.

This work was completed as a Google Summer of Code 2026 project.

Sponsor: Google Summer of Code 2026

Contact: Hans Rosenfeld <rosenfeld@grumpf.hope-2000.org>

Links:
Bhyvemgr URL: https://github.com/alonsobsd/bhyvemgr/
Bhyvemgrd URL: https://github.com/alonsobsd/bhyvemgrd/

Contact: José Alonso Cárdenas Márquez <acm@FreeBSD.org>

Bhyvemgr is a bhyve management GUI written in Freepascal/Lazarus on FreeBSD. It needs a bunch of tools, mostly installed on base system, and some installed from ports/packages. The main goal is to be a desktop application with focus on desktop users to easily and quickly setup and run virtual machines on FreeBSD hosts.

Starting with version v2.0.0, bhyvemgr was migrated to client/server architecture. As a result, a server component was developed. This new component is called bhyvemgrd.

Bhvemgrd supports two ways to run privileged tasks: mac_do/mdo (FreeBSD >= 140000) and mac_do/setcred/exec_paths (only for FreeBSD >= 1501501). The process itself run under an unprivileged bhyvemgrd user.

During last two quarters, there were many bugfixes and improvements to Bhyvemgr.

These are some highlights that were added:

Bhyvemgr and Bhyvemgrd supports aarch64 from 15.x to 16-CURRENT and amd64 from FreeBSD 14.x to 16-CURRENT. Bhyvemgr can be compiled or installed from sysutils/bhyvemgr with gtk2, qt5, or qt6 interface support. Bhyvemgrd can be compiled or installed from sysutils/bhyvemgrd.

People interested in helping or supporting the projects are welcome.

Current bhyvemgr version: 2.1.0 Current bhyvemgrd version: 1.2.0

Sponsor: https://paypal.me/alonsocbsd

Links:
Laptop Support and Usability Project Task URL: https://github.com/FreeBSDFoundation/proj-laptop/issues/25
Project repository URL: https://gitlab.com/alfix/kde-installer-dialogs

Contact: Alfonso S. Siciliano <asiciliano@FreeBSD.org>

The goal of this project is to provide a simple feature in bsdinstall(8), the FreeBSD system installer, to install and configure a graphical environment. The installer should ask users whether they want to install a desktop environment and, if so, automatically install and configure everything needed with minimal or no user intervention. After reboot, users should be presented with a graphical login screen.

In the first 2026 status report, a possible solution was described: a shell script of approximately 400 lines of code to install and automatically configure the components required for a graphical desktop environment, including GPU drivers, Xorg, KDE Plasma, and SDDM. After a call for testing, which received a significant amount of feedback from users, review D56167 was submitted to add the new desktop script to bsdinstall.

After the review was submitted, several discussions took place about the proposed implementation. As a result of the review, it was requested to split the script into smaller components and move part of its functionality into separate ports. The review, D56167, is now obsolete. Several possible approaches were then analyzed and tested.

The chosen solution is to create new ports with flavors.

The base port provides the tools to build menus and/or return to the script a list of packages to install. The menu utilities are implemented as shell scripts because the design of a Lua API for the text user interfaces is still in progress.

Each flavor provides a pkg-post-install-lua(5) script to configure the package installed on the new system. pkg-post-install-lua was chosen instead of the pkg-post-install(5) shell script because it will make it easier to reuse the code if it becomes necessary to use pkg-trigger(5) in the future.

The following four new ports with flavors, with a total of 26 packages, have been created and submitted to Bugzilla:

A new draft of the desktop script has also been completed in the project repository. It is significantly different from the original script and is now approximately 100 lines of code. A new review to add the desktop script to bsdinstall will be submitted after the new ports have been added to the Ports Collection.

This is still an experimental feature. In the future, depending on user interest and feedback, the desktop script can be further improved to support additional desktop environments and graphical tools.

Sponsor: The FreeBSD Foundation

Links:
Website URL: https://sylve.io
GitHub URL: https://github.com/AlchemillaHQ/Sylve
CI URL: https://sylve-ci.alchemilla.io
Discord URL: https://discord.gg/bJB826JvXK

Contact: Hayzam Sherif <hayzam@alchemilla.io>

Sylve is a modern, unified system management platform for FreeBSD. It provides an integrated web interface for managing virtual machines (via Bhyve), Jails, the networking around them, and ZFS storage.

The backend is implemented in Go, while the frontend is built with Svelte. The project emphasizes a minimal system footprint. By default, it does not require any packages outside of the base system.

Optional runtime dependencies, required only when their respective features are used, include:

The port pulls in these dependencies for convenience to the user, but by itself, Sylve needs no dependencies to run.

Links:
Accessibility Handbook URL: https://docs.freebsd.org/en/books/accessibility/
Project repository URL: https://gitlab.com/alfix/freebsd-accessibility/
LearnBraille URL: https://gitlab.com/-/snippets/6065143
bsddialog URL: https://gitlab.com/alfix/bsddialog

Contact: Accessibility <accessibility@FreeBSD.org>
Contact: Alfonso S. Siciliano <asiciliano@FreeBSD.org>

Vision Accessibility is a project focused on improving visual accessibility in FreeBSD by documenting, developing, and integrating assistive technologies for blind and visually impaired users.

Links:
x11appjail on GitHub URL: https://github.com/DtxdF/x11appjail
Contact: Jesús Daniel Colmenares Oviedo <dtxdf@FreeBSD.org>

x11appjail is a specialized tool for creating, verifying, installing, and running AppJails. An AppJail is a CLI, TUI or X11 application that runs inside a FreeBSD jail but is perceived by the end user as identical (or at least very similar) to an application running directly on the host system.

This tool makes extensive use of appjail(1) as its engine; however, unlike the latter, the primary user in x11appjail is neither root nor a privileged user, but rather an unprivileged user. The fundamental goal of this project is to grant the user limited access to the jail, restricted solely to the execution of a CLI, TUI or X11 application.

This project began months ago as a prototype to establish a workflow leveraging appjail-x11(1); however, starting with version 1.0.0, it was rewritten from scratch into a unified tool that integrates all its projects, such as sysutils/appjail, sysutils/unixexec, archivers/appscript, and sysutils/jtransfer, among others. Even better, it allows for the execution of not only X11 applications but also CLI and TUI programs.

The most relevant project for x11appjail(1) is not only appjail(1), but also appscript(1). My goal with appscript(1) is to create an ultra-lightweight alternative to AppImage for FreeBSD that does not depend on FUSE, thus eliminating the need to configure vfs.usermount=1. appscript(1) allows you to create an elf(5) executable that contains everything necessary to run a self-contained executable.

The most significant changes and improvements for appscript(1) and x11appjail(1) are:

Another notable change worth mentioning for x11appjail(1) are the examples added in ${EXAMPLESDIR}/Apps: badwolf, chromium, evince, feh, firefox, htop, linux-brave, mpv, nanonote, telegram-desktop and thunderbird. Beyond the applications themselves, the key factor is the deployment method. htop is an example of a CLI application, linux-brave is a Linux application, and the others are X11 applications. Web browsers, Mpv, and Thunderbird are the most interesting examples, as they demonstrate how an AppJail can use VirtualGL to properly enable hardware acceleration within a FreeBSD jail, something that would not normally be possible given that Xephyr is the backend used by appjail-x11(1). Best of all, from the end-user’s perspective, all of this is transparent.

Demo video: https://youtu.be/EBSMHBC0Phc

Sponsor: https://www.patreon.com/appjail

Links:
link: The commit series of the port URL: https://github.com/linux-rdma/rdma-core/pull/1778
link: LinuxAPI project URL: https://github.com/freebsd/linuxapi

Contact: Konstantin Belousov <kib@FreeBSD.org> Contact: Ariel Ehrenberg <aehrenberg@nvidia.com> Contact: Slava Shwartsman <slavash@nvidia.com> Contact: Gleb Popov <arrowd@FreeBSD.org>

The Remote Direct Memory Access (RDMA) infrastructure provides high-performance interconnect between computing and storage nodes. It can operate over different physical networks, for instance Ethernet and Infiniband.

The implementation of the RDMA stack consists of several components. There is the core kernel infrastructure, and drivers for Host Channel Adapters (HCAs), providing access to the kernel verbs. Userspace applications never interact with the kernel devices directly, the core libibverbs library and vendor-specific userspace drivers provide unified and device-specific verbs.

Since RDMA intent of providing low-latency low-overhead operations, performant HCAs offload a lot of operations from CPU. Also, typical in-line operations like send and receive can be initiated and completed in userspace, where kernel only assists in the connection establishment and teardown. Due to this, the userspace RDMA software stack is crucial for its operations.

FreeBSD base system includes port of the so called OFED kernel core component, kernel drivers, as well as userspace core (libibverbs) and userspace drivers, for instance libmlx5 for managing Nvidia Connect-X4 and later HCAs. Over time, the kernel parts get some significant updates from the infiniband code in the Linux kernel, which become the home for updated OFED. Userspace part of OFED was converted into the rdma-core userspace project, that only supports Linux (and glibc). Since userspace drivers in rdma-core provide essential functionality, and since FreeBSD userspace RDMA components are quite outdated, the situation overall needs a resolution.

We attempted to update the in-tree userspace components by importing the series of rdma-core commits with dependencies, but it quickly proved to be not feasible. Instead we started looking at what it would take to make rdma-core compile and run on FreeBSD.

First, there were a number of missing glibc-specific APIs that were used in rdma-core, for instance, strdupa() and friends, main:tdestroy(3), some pthread functions. These were easy to handle in the base system, and addition of them benefited the whole FreeBSD porting story.

Next, and more serious, the unportable features of glibc were used everywhere in the sources, and trying to cover them all would cause huge porting patch, which is problematic to push upstream, even for cooperating upstream. Instead, the idea of using an approach similar to LinuxKPI for kernel code, was formed and developed, called LinuxAPI. Unlike LinuxKPI, which handles architectural mismatches between Linux kernel and FreeBSD kernel, in addition to the different C interfaces, LinuxAPI needs to smooth out the differences around extensions to the same core functionality defined by POSIX. It is mostly about bits that are not defined by POSIX but needed for RDMA to function, like networking interface enumeration, or discovery of the rdma-capable devices and their capabilities etc.

It seems that people consider the LinuxAPI useful outside the rdma-core porting efforts already, there is a project github.com/freebsd/linuxapi which takes the developed set of headers and extends it further. We are currently working on providing the permissive license to make the library useful without additional strings attached.

Our initial goal, also limited by the available hardware, is to have rdma-core work with the ConnectX-4 cards. Of course we welcome all vendors interested in RDMA on FreeBSD to improve the port to properly support their cards.

The result of the porting is available as the repository. Also we try to upstream the changes so that FreeBSD would become the second natively supported platform for rdma-core. The Pull Request to the github project is submitted. There is currently a blocking discussion about the way to organize CI for FreeBSD platform. Gleb Popov created the net/rdma-core port from the forked sources, which is already in the ports tree.

The kernel changes to get the port working were surprisingly small and contained. They mostly consisted of bug fixes for the code paths not previously exercised by userspace since there were no userspace. Most interesting part was perhaps the difference in ioctl(2) behavior between Linux and FreeBSD, where Linux can both return an error and copyout the data structure. The issue was already observed in the LinuxKPI, and the porting work provided the generic solution there.

Sponsor: Nvidia networking

Links:
Up-to-date NFS server sources in branch freebsd-rdma URL: https://github.com/viniciusferrao/freebsd-src.git nfs-over-rdma-setup.txt URL: https://people.freebsd.org/~rmacklem/nfs-over-rdma-setup.txt

Contact: Rick Macklem <rmacklem@freebsd.org>, Vinicius Ferrao <ferrao@versatushpc.com.br>

Currently FreeBSD’s NFS is supported over TCP (and UDP for NFSv3). This project adds support for NFS over RDMA, as described by RFC-8166 and RFC-8267. This should allow RDMA aware NICs to offload most of the network transport and improve performance over fast LAN fabrics.

Thanks to Vinicius, a lot of progress has been made. He has the NFS server side working, and quite well from what I know.

The client side is now testing quite well against Vinicius’s server and both client and server are now ready for third party testing. To test, a client and server with Mellanox ConnectX4→6 NICs running a kernel built from recent FreeBSD main sources is needed.

See nfs-over-rdma-setup.txt for information on setting up a testing environment.

A stable/15 kernel should be sufficient for the loadable modules in a few weeks. The client code should also be committed to FreeBSD’s main in a few weeks, with an MFC to stable/15 be the end of 2026. The server code was created via generative AI and the FreeBSD project is working on a policy for handling generative AI submissions. In the meantime, the server code will be available as an "unofficial port" that builds a kernel loadable module.

Third party testing would be appreciated.

Thanks go to Vinicius for the NFS server work and to the FreeBSD Netperf cluster folk, without which I would have never gotten this code tested.

Sponsor for the NFS server code: Verastus HPC

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

Contact: Devin Teske <dteske@FreeBSD.org>

nfsstat(1) reports the server as a whole. nfsdtop(8) reports the user, the group, or the client behind the reads and writes. It is a top-like display, taken with dtrace(1) from the nfsd(8) paths nfsrvd_read, nfsvno_read, nfsrvd_write, and nfsvno_write.

The default view is per user. -g coalesces by group, and -c by IPv4 client. Each interval prints a total, then the rows that did the I/O, sorted by combined read and write volume. The default interval is two seconds. The columns are humanized bandwidth unless -b asks for the bytes moved in that interval. WRITE(IN) is data the clients sent. READ(OUT) is data the server sent.

A UID, GID, or client address on those paths belongs to the client, not to the server. nfsdtop(8) does not ask getent(1) to name them while it samples. Names come from map files in the current directory: .nfsd.passwd, .nfsd.group, and .nfsd.hosts. A filter (-U, -G, or -C) is resolved once, from those maps and then with getent(1) or host(1), and the result is compiled into the dtrace(1) predicate.

-j emits one JSON object for the view total and one per key, each interval, with the byte counts and the rates. -J samples the client, group, and user views together:

Only root, or a user who can run dtrace(1), can run it. The client view and -C are IPv4 only. -R, or a non-empty NFSDTOP_REDACT, replaces names that are not well-known system accounts with random strings of the same length.

The introduction is in HEAD as of 60c7313074b9 (D59438), and nfsdtop(8) makes its first release in FreeBSD 16.0.

Thanks to Alexander Ziaee and Benedict Reuschling for the man page, to Adrian Chadd for review, and to Rick Macklem for a look at the NFS side.

Run it on a server that is already busy. If the row you need is not a user, a group, or a client, please write.

Links:
GSoC project Wiki page URL: https://wiki.freebsd.org/SummerOfCode2026Projects/EnhancingZonedStorageSupportOnFreeBSD

Contact: voidanix <voidanix@FreeBSD.org>

Contact: Minsoo Choo <mchoo@FreeBSD.org>

I was off for university from May to August and I am back to working on this now. Since I could not accomplish this task for LLVM 23, the target release for completion has changed to LLVM 24.

armv7 and powerpc64be are support candidates now. Once LLDB refactoring is done, I will implement support for those architectures.

Unlike KGDB that uses custom frame sniffer for trapframe unwinding, LLDB uses DWARF CFI instead. DWARF CFI works on KGDB as well; when a frame is not recognized by KGDB’s frame sniffer, it will fall back to CFI. Thus, no change on the KGDB side is needed.

Sponsor: The FreeBSD Foundation

Contact: Konstantin Belousov <kib@FreeBSD.org>

The process descriptors API enhancements project continued, with the goal to allow complete process control using descriptors, in particular, debugging. I wanted to make it possible to stop reference pids as the process identifiers. The milestone for it should be a demonstration of enabling the capsicum mode for some non-trivial debugger, I selected truss(1) because it does not need neither filesystem nor network namespace accesses after attached to the target.

The semi-obvious solution there is to introduce pdptrace(2), which is equivalent to ptrace(2) but takes the process descriptor as the process designator. We need to be able to obtain the notifications of the process debugging events, which are provided by waitpid[2] syscall family for pid-based controls. And, we need a way to obtain the process descriptor for a new child forked from the debuggee, to continue tracing of all descendants.

Previously, the pdopenpid(2) system call was added, which allows to get a handle on an arbitrary process. Existing operations on the process descriptors are somewhat limited: handle owner can wait for the exit notification using kqueue(2), and with some luck retrieve the process exit status.

The last point requires some elaboration. Since the pdwait(2) call was added recently, there were some amount of hacks in the kernel to allow waitpid(2) calls on pid’s of processes created with pdfork(2). As result, the waitpid(2) caller might have reaped the process before owner of the process descriptor could call pdwait(2). Similarly, if there is more than one process descriptor opened on the same process, only the first pdwait(2) caller could retrieve the exit status with pdwait(2), making other descriptors useless.

The listed set of problems also made it very hard to correctly use the proposed pdptrace(2). The process being debugged could steal events from process descriptors and vice versa. Simply disallowing wait(2) on processes with the opened descriptors is not an option for two reasons: * backward compatibility, waitpid(2) was already allowed and existing binaries relied on it * if the debuggee used fork(2) to create a child, it expects to get the exit notification (e.g. SIGCHLD) and exit status from wait(2)

The solution was manyfold. First, we have to postpone reaping if there are either opened process descriptors, or if the process was created with fork(2), we should not reap until wait(2) is called on pid by the parent. Second, the exit status needs to be preserved in the process descriptors private data even after reaping, to allow pdwait(2) on any of the descriptors. This was implemented by providing a bitmap of the 'zombie refs' on the kernel struct proc. Each zombie reference prevents reaping, and cleared by corresponding call to waitpid(2) or pdwait(2). Only when all registered references are cleared, zombie can be reaped. If the process is created with pdfork(2) or opened with pdopenpid[2], it gets the procdesc zombie reference. If the process was created with fork(2), it gets the 'parent' zombie reference. By default, pdfork[2] also sets the parent reference to allow the waitpid(2), for compatibility. The new pdfork(2) flag PD_NOWAITPID prevents that.

Then, wait-like events must work with the process descriptors. The procdesc kqueue(2) event filter was extended with NOTE_PDSIGCHLD hints to report that pdwait(2) can retrieve tracing or exiting event on the descriptor.

Then, the pdptrace(2) was able to usefully control the target. A new ptrace call to retrieve the list of the attached processes PT_GET_CHILDREN allowed pdptrace(2) to get hold of forks.

With all the features implemented, it was possible to convert truss(1) to use only process descriptors to control the traced processes. The existing mode of using pids was preserved, and can be selected with the '-y' option as an emergency switch and to easy comparison and debugging of the new mode.

Sponsor: The FreeBSD Foundation

Links:
EuroBSDCon 2026 DevSummit Wiki page URL: https://wiki.freebsd.org/DevSummit/202609
Slides URL: https://wiki.freebsd.org/DevSummit/202609?action=AttachFile&do=view&target=EuroBSDCon2026-Scheduler.pdf

Contact: Olivier Certner <olce@FreeBSD.org>
Contact: Minsoo Choo <mchoo@FreeBSD.org>

This quarter, a number of fixes and cleanups were merged to ULE and 4BSD:

Work is on-going and nearing completion on cleaning up the machinery allowing multiple scheduler implementations (a.k.a., "instances") to co-exist in the same kernel. From a single list of function descriptors, it now automatically produces the declaration of functions in the scheduler interface and in scheduler instances, the fields of the scheduler instance descriptor structure and the dispatching functions. A second round of changes is in preparation, with the aim to potentially remove implementation functions' namespacing (e.g., having ule or 4bsd in their names) in the source code, in effect renaming them back to their old names, which are those of the interface functions, while keeping the namespacing for C symbols which is required for debugging and in general manipulation by various ELF tools.

Work continues in the background on solutions to long-standing shortcomings in the ULE scheduler such as unfairness for non-interactive threads in certain particular circumstances and the very weak effect of nice values. For more information, please consult the previous report, and the slides of the latest presentation at EuroBSDCon2026’s DevSummit.

Sponsor: The FreeBSD Foundation

Links:
D59275 URL: https://reviews.freebsd.org/D59275
rGaf25f2476230 URL: https://cgit.freebsd.org/src/commit/?id=af25f24762307bf606690c0aca6a3205a0515914

Contact: Devin Teske <dteske@FreeBSD.org>

truss(1) traces the system calls a process makes. Until this quarter it reported every call, which for anything larger than a toy program buries the calls of interest.

HEAD now accepts -t with a comma-separated expression naming the system calls to report. The option letter is the one System V Release 4 and SunOS truss use for this. A term may be a system call name, an fnmatch(3) glob (readlink*), a system call number in the traced process’s ABI, or @group for a family of related calls. A leading ! excludes what that one term matches and applies to no other term — unlike SVR4 truss and Linux strace, where ! is sticky for the rest of the list. Terms apply in order; the last match wins. truss -t with no expression lists the groups and exits.

Groups are themselves -t expressions, so they compose without a second language. @desc is built from @read and @write rather than repeating their members. Member lists are patterns (extattr_*file, sctp*) rather than frozen name lists, so a later system call that follows the same naming convention joins the right group without a source change here.

Thirteen groups ship to start: @all, @creds, @desc, @file, @ipc, @memory, @net, @none, @proc, @read, @signal, @time, and @write. They are not a clone of Linux strace’s `% classes: @read and @write split descriptor data-in from data-out, and @time covers clocks, timers, and sleeping rather than clocks alone.

Show only the file and network activity of a command:

Show everything a command does except its memory management:

Show the descriptor activity of a running process apart from the data transfers themselves:

Count the readlink(2) and readlinkat(2) calls made while starting a program:

A system call excluded by -t is not decoded, so the filter also skips the cost of formatting arguments that would never be printed, and it is left out of the -c summary. Without -t, behaviour is unchanged.

The work is in HEAD as of af25f2476230, with an MFC planned after two weeks. Thanks to Robert Clausecker for review, and to Alexander Ziaee for the man page pass.

If a call you care about is in the wrong group, or a group you would use is missing, please write.

Links:
D58066 URL: https://reviews.freebsd.org/D58066
rG3fe5961a0b70 URL: https://cgit.freebsd.org/src/commit/?id=3fe5961a0b708da599d42cbb6b5e4f030c28ea45

Contact: Devin Teske <dteske@FreeBSD.org> Contact: Faraz Vahedi <kfv@FreeBSD.org>

sysctl(8) speaks to the running kernel. sysrc(8) speaks to rc.conf(5). This quarter the set became three, and the new tool is a pleasure to use. sysconf(8) reads and writes the rest of the base configuration: loader.conf(5), sysctl.conf(5), and the make.conf(5) family (make.conf, src.conf, and src-env.conf). The syntax is the one your fingers already know. Given simply a name, reads back the value of the given name. name=value writes, and the reply comes back in the familiar line: name: old → new.

The next boot setting fits on one line:

rc.conf(5) keeps the tool that already does it best. sysconf rc sshd_enable=YES hands every argument after rc straight to sysrc(8). One front door, and the right specialist behind it.

Under the utility is bsdconf(3), the figpar engine brought forward as one reader and one writer, co-authored with Faraz Vahedi. Each file family is a small descriptor: the keyword, the files, and the quoting rules of the program that will actually read them. Loader values are written quoted, because that is what the boot loader accepts. Sysctl values are quoted only when the round trip needs it. The make family keeps its real operators (+=, ?=, :=, !=) and the empty WITH_ / WITHOUT_ assignment, because for those knobs presence is the setting. You name the format with the target. -f names the path, so a loader-formatted file staged anywhere is still a loader file, and a generic target covers a file that matches no built-in.

Where the boot reads several files, sysconf reads those same files, in that same order. The loader target starts where the loader starts, at /boot/defaults/loader.conf, and follows loader_conf_files, loader_conf_dirs, and local_loader_conf_files, including a layout that points those lists somewhere else. The value you read is the value that takes effect. The value you write is stored where it will still take effect on the next boot. A removal clears every file that lists the directive, so that an earlier setting does not simply get unmasked. The same command lists the files and dumps the effective set:

-d reports the descriptions carried in the defaults file. -A widens a dump so directives still at their default are part of the picture.

A write replaces the file whole. The new text goes to a temporary in the same directory, is fsynced, and is renamed over the original, with mode and ownership preserved. If the machine stops halfway, the previous file is the one still on disk. Read-only use, a -c check included, runs inside a capsicum(4) sandbox: the files are opened, every other capability is dropped, and only then is a line parsed.

The sysctl target asks the running kernel before it stores anything. An unknown OID, a read-only OID, a loader-only tunable, or a value outside the type’s range is reported and skipped, and a loader-only tunable is pointed at the loader target, where a boot setting belongs. Every other assignment in the same command still applies. On make and src, WITH_foo=no is written and you are told at once to use WITHOUT_foo=1 instead. That is the advice in share/mk/bsd.mkopt.mk, delivered at the keyboard, and repeated on a later read with the file and line so an old WITH_*=no stays in view.

-j and -R aim the same sentences at a jail or another root.

The introduction is in HEAD as of 3fe5961a0b70 (D58066), and sysconf(8) makes its first release in FreeBSD 16.0. It has already grown since that commit. A unique prefix of a target is enough (lo is loader, sy is sysctl, sr is src), and a poudriere target carries the same verbs to poudriere.conf and the make overlays under poudriere.d.

Thanks to Robert Clausecker and Faraz Vahedi for review, and to Alexander Ziaee for the release notes.

Try it on HEAD against a file you usually open by hand. If a format you live in is missing, please write. The descriptor layer is how the next one joins, and it would be good to hear which file you want next.

Contact: Christos Margiolis <christos@FreeBSD.org>

At the end of this quarter, I started working on improving cuse(3). Apart from minor fixes and refactors, I fixed known hangs in the kernel module during I/O (872c36cb6f2d) and module hot-unload (d38ef1aca969).

You can also follow the development process on the FreeBSD Foundation’s status-updates repository, where I post weekly reports.

Sponsor: The FreeBSD Foundation

Links:
Working branch URL: https://github.com/realchonk/freebsd-src/tree/ext2fs-user-tools

Contact: Benjamin Stürz <benni@FreeBSD.org>

The goal of this project is to implement tools for managing ext2fs filesystems in base FreeBSD.

The project includes the following: - dumpfs_ext2fs(8) - newfs_ext2fs(8) - fsck_ext2fs(8) - tunefs_ext2fs(8) - libext2fs (same idea as libufs) - integration into makefs - tests for the mentioned components

Sponsor: The FreeBSD Foundation

Links:
Boot loader test framework URL: https://reviews.freebsd.org/D58008
XZ decompression for EFI memory disks URL: https://reviews.freebsd.org/D58073
Dynamic loader memory disks URL: https://reviews.freebsd.org/D59418
Independent EFI HTTP devices URL: https://reviews.freebsd.org/D59423
DHCP initial memory-disk option URL: https://reviews.freebsd.org/D59428
EFI chain-boot partition fix URL: https://cgit.freebsd.org/src/commit/?id=9ecc2493ca5fbba852e175674b5cb8975b99af84

Contact: Warner Losh <imp@FreeBSD.org>

Work this quarter expanded the boot loader’s support for compressed images, memory disks, and HTTP network booting, with an eye to both iPXE integration, and loader.efi(8) completeness. It also introduced a QEMU-based test framework covering many of FreeBSD’s boot combinations.

The loader can now read files compressed with XZ or Zstandard in the same way that it already handled gzip and bzip2 files. XZ support is enabled by default in the BIOS and EFI loaders, including support for compressed memory-disk images such as FreeBSD installation images. Zstandard support is available as a build option.

Memory-disk handling was generalized so that the loader can create an md device dynamically. This provides a fallback on systems whose UEFI firmware does not implement the RamDisk protocol, a situation found on some smaller and embedded systems. The resulting memory disk is exported to the kernel and can contain both the kernel and the root filesystem. Downloaded memory-disk images now use the correct UEFI memory type, and downloads can be interrupted with Escape. This replaces the need to use the memdisk_uefi.efi third-party add-in that people needed previously for iPXE integration. Now loader.efi can also download images via iPXE’s download services, requiring only basic networking DXE modules in the UEFI firmware image.

EFI HTTP support previously depended on the firmware having loaded loader.efi through UEFI HTTP Boot and was restricted to the server selected by the firmware. The loader now accepts arbitrary http[N]://host[:port]/path device specifications. These can be used as rootdev, in loader.conf, or interactively, regardless of how the loader itself was started. The implementation can either reuse an existing loader network configuration or ask the firmware network stack to perform DHCP.

The DHCP client now requests a FreeBSD vendor option containing the URL of an initial memory-disk image. With this option, a machine can start loader.efi directly over the network, discover a detached root image through DHCP, retrieve that image over HTTP, and boot from it. Care was taken to transfer ownership of the network interface between the loader’s native network stack and the UEFI HTTP stack. This is necessary because each stack needs different access to the firmware’s network protocols.

A new tools/boot/boot-test.sh framework uses QEMU to test booting across aarch64, amd64, armv7, powerpc64, powerpc64le, and riscv64. It exercises the applicable BIOS, UEFI, OpenFirmware, and PReP environments with CD, MBR, GPT, network, and memory-disk configurations, as well as the Lua, Forth, and simple loaders. HTTP network-boot and gptboot.efi chain-boot tests were added later in the quarter. The framework is not yet an installed test because it builds and tests several target architectures from one host.

The chain-boot tests accompanied a fix for systems that use gptboot.efi to select between A/B system partitions. After being chain-loaded, loader.efi could skip the selected partition and boot the other system partition instead. The selected partition is now tried first, while the normal search of sibling partitions remains as a fallback. A separate loader change that interfered with some ZFS chain-boot configurations was reverted.

Other work added a loader.kboot(8) manual page, build knobs for omitting the x86 BIOS and userboot loaders from UEFI-only systems, and defensive checks for firmware that advertises unusable graphics output protocols.

Sponsor: Netflix

Links:
Blog URL: https://obiw.ac/s0ix/
BSDCan talk on s2idle/S0ix URL: https://youtu.be/RCjPc4X2Edc
Working branch URL: https://github.com/obiwac/freebsd-s0ix/pull/15

Contact: Aymeric Wibo <obiwac@FreeBSD.org>
Contact: Olivier Certner <olce@FreeBSD.org>

Suspend-to-idle and support for S0ix sleep is in the process of being added to FreeBSD.

This will allow modern Intel and AMD laptops, some of which do not support ACPI S3 sleep, to enter low power states to increase battery life.

amdsmu(4) now proactively diagnoses S0i3 entry after resuming from suspend-to-idle with a new eventhandler. If S0i3 was not entered, it will print the IP blocks that were blocking entry to dmesg, along with hints on how to resolve them.

The acpi_spmc(4) driver now checks Intel and AMD constraint packages. Malformed constraints are skipped instead of crashing.

Various improvements were made to the thunderbolt(4) driver: support for writing to router config space, controller resets, and a CRC accounting fix for config write messages. Thunderbolt controllers can now be resumed (in review), which allows multiple suspend-resume cycles without needing to reload the kernel module.

At this point modern standby works reliably on target laptops and most panics have been ironed out. The primary issue being worked on is GPE events generated while the machine is suspended — such as plugging or unplugging AC power — causing panics.

Sponsor: The FreeBSD Foundation

Contact: Christos Margiolis <christos@FreeBSD.org>

I have been working on the audio stack since 2024Q1. Below is a list of the previous status reports:

2024Q1 URL: https://www.freebsd.org/status/report-2024-01-2024-03/#_audio_stack_improvements
2024Q2 URL: https://www.freebsd.org/status/report-2024-04-2024-06/#_audio_stack_improvements
2024Q3 URL: https://www.freebsd.org/status/report-2024-07-2024-09/#_audio_stack_improvements
2024Q4 URL: https://www.freebsd.org/status/report-2024-10-2024-12/#_audio_stack_improvements
2025Q1 URL: https://www.freebsd.org/status/report-2025-01-2025-03/#_audio_stack_improvements
2025Q2 URL: https://www.freebsd.org/status/report-2025-04-2025-06/#_audio_stack_improvements
2025Q3 URL: https://www.freebsd.org/status/report-2025-07-2025-09/#_audio_stack_improvements
2025Q4 URL: https://www.freebsd.org/status/report-2025-10-2025-12/#_audio_stack_improvements
2026Q1 URL: https://www.freebsd.org/status/report-2026-01-2026-03/#_audio_stack_improvements
2026Q2 URL: https://www.freebsd.org/status/report-2026-04-2026-06/#_audio_stack_improvements

Important work since last report:

You can also follow the development process on the FreeBSD Foundation’s status-updates repository, where I post weekly reports.

Sponsor: The FreeBSD Foundation

Links:
Wiki page URL: https://wiki.freebsd.org/BoundsSafety
Project page URL: https://freebsdfoundation.org/project/adopt-fbounds-safety-in-the-freebsd-kernel-tcp-ip-stack/

Contact: Abhijeet Sharma <abhijeetsharma2002@gmail.com>

Clang’s -fbounds-safety lets C code state a buffer’s length, as in __counted_by(len). The compiler then checks accesses through that pointer. An out-of-bounds access traps instead of corrupting memory. The TCP/IP stack parses untrusted network input, so it is a good place to start. This project adds the macros and build support, then converts TCP files one at a time. Without the flag the annotations expand to nothing. The tree still builds with the base system compiler and with GCC.

Contact: Pouria Mousavizadeh Tehrani <pouria@FreeBSD.org>

Following the geneve(4) work, I have been migrating our other tunnel drivers to the new if_clone KPI and adding netlink support for them, both in kernel and in ifconfig(8). They are now available on CURRENT.

So far, I have added the support for:

While here, I fixed the following bugs:

Ongoing work:

Links:
Project Page

Contact: Ishan Agrawal <ishan@freebsd.org>

Mentor: Kristof Provost <kp@freebsd.org>

PF uses Netlink to communicate between userland tools and the kernel, but before this work, truss(1) could not meaningfully decode the payloads of PF Netlink messages and would instead display much of the message as raw data.

This project adds a reusable Netlink payload decoding infrastructure to libsysdecode and integrates it with truss(1), allowing structured decoding of Netlink messages rather than exposing only their raw contents.

The core of the infrastructure is a generic attribute decoder based on decoder tables. The infrastructure supports decoding different attribute types, including integer values, strings, booleans, and nested attributes. Netlink commands can then provide their own decoder tables describing the attributes they contain, without requiring a separate decoding mechanism for each command.

The infrastructure has been used to add decoding for several PF Netlink commands, including PFNL_CMD_KILLSTATES, PFNL_CMD_GETRULES, and PFNL_CMD_GET_LIMIT.

For example, a PF Netlink message that previously appeared largely as an opaque buffer:

With the new decoding infrastructure, truss(1) can decode the Netlink message and PF payload into meaningful fields, for example:

truss(1) was also extended to track the protocol associated with AF_NETLINK sockets so that messages can be passed to the appropriate decoder. Netlink message flags are decoded as combinations of NLM_F_* flags, while unknown bits are preserved.

The work in this quarter established the infrastructure needed to continue adding PF Netlink payload decoders without duplicating parsing logic for each command.

Sponsor: Google LLC (GSoC 2026)

Links:
Support the MediaTek Wireless cards URL: https://github.com/FreeBSDFoundation/proj-laptop/issues/66
MediaTek mt76 Wiki page URL: https://wiki.freebsd.org/WiFi/Mt76
Wireless Problem Reports URL: https://bugs.freebsd.org/bugzilla/showdependencytree.cgi?id=277512&hide_resolved=1
Espressif Systems ESP32-E22 URL: https://www.espressif.com/en/products/socs/esp32-e22
Espressif WiFi Driver github URL: https://github.com/espressif/esp32e22-linux-driver

Contact: Bjoern A. Zeeb <bz@FreeBSD.org>
Contact: The FreeBSD wireless mailing list <wireless@FreeBSD.org>

This report focuses on the efforts using permissively licensed Linux wireless drivers, mostly unmodified, on FreeBSD, as well as preparing the native net80211 stack for support of newer standards.

Contact: Pouria Mousavizadeh Tehrani <pouria@FreeBSD.org>

Since the last report, I have continued refreshing our IPv6 stack and implementing pending RFCs, and the results are now available on CURRENT.

So far, I have added the support for:

I also fixed a few bugs in the stack:

Ongoing work:

I want to especially thank Marek Zarychta for his tests and reviews.

Contact: Pouria Mousavizadeh Tehrani <pouria@FreeBSD.org>

For the past 3 months, I have worked on improving the resilience of our routing stack, and the results are now available on CURRENT.

Previously, the reachability of every nexthop was checked against the interface link status for each packet. Now, nexthops subscribe to interface link events and only the reachability flag of the final nexthop is checked in the forwarding path. When a nexthop becomes unreachable, the nexthop groups that contain it are recompiled immediately by replacing the unreachable nexthops with the reachable ones. Once the link comes back, the nexthops return to their normal slots in the nexthop group. This means a multipath route keeps forwarding traffic when one of its links goes down, without deleting the route. I am really proud of this one.

So far, I have added the support for:

I also fixed a couple of bugs in fib_algo:

I want to especially thank Gleb Smirnoff, Alexander Chernikov and Mark Johnston for their reviews and guidance on these works.

Links:
Phabricator revision URL: https://reviews.freebsd.org/D59140
Reproducer and epistemic record URL: Reproducer and epistemic record

Contact: Luis Castellanos <ing.castellanosdz@gmail.com>

Links:
CAM lifecycle DTrace probes URL: https://reviews.freebsd.org/D58523
CAM peripheral invalidation events URL: https://reviews.freebsd.org/D58527
mpsutil discovery information URL: https://reviews.freebsd.org/D58528

Contact: Warner Losh <imp@FreeBSD.org>

Several changes this quarter made storage-device discovery easier to observe and diagnose, particularly during boot.

The CAM DTrace provider gained probes for peripheral I/O errors, error recovery, and peripheral invalidation. Additional probes report when CAM holds or releases the boot process and when a new bus is registered. Together these probes cover much more of the path from initial bus discovery through the creation of disk peripherals. They can also be used with DTrace anonymous tracing to investigate problems that happen before the system reaches multi-user operation. The new probes are documented in dtrace_cam(4).

CAM now sends a devctl(4) notification when a peripheral is invalidated. The notification includes the device serial number when available, or its CAM path otherwise, so system-management software can identify the device that disappeared. The common code used to construct CAM notifications was factored out to support this and future event types.

Two fixes improved the handling of disks that fail during probing. CAM now stops probing after a peripheral has been invalidated instead of sending more commands to an abandoned device, where they could cause long timeouts and confusing errors. A related condition for deciding when to invalidate a disk was corrected. Errors reported for NVMe disks through the CAM nda peripheral now identify the command set, making command opcodes easier to interpret.

mpsutil(8) gained a show discovery command that prints the controller’s discovery tables. This exposes the controller’s view of attached SAS devices and expanders and is useful when diagnosing devices that are missing or attached through an unexpected path.

Finally, nvmecontrol(8) received correctness fixes for Autonomous Power State Transition data. Transition values are now encoded without intermediate integer overflow, and identify data reporting an excessive number of power states is handled with a bounds check rather than an assertion.

Sponsor: Netflix

Contact: Konstantin Belousov <kib@FreeBSD.org>

Most non-x86 platforms are relatively strict with regard to the proper alignment of the data types. On the other hand, x86 ISA allows any alignment for the operands of integer scalar operations.

Still, there is an AC control bit in the processor flags register which causes alignment exception (fault) on unaligned operations. Practically the bit is not too useful because most of the compilers generate code that relies on the freedom of the working unaligned access on x86.

Particularly interesting case of the unaligned access is when the disposition of the operand causes it to span two cache lines (which is impossible for naturally aligned data). Normal (unlocked) operations cause so called torn reads and writes. This effect become observable starting with Core2 Intel microarchitecture.

Even more interesting case is provided by the locked operations using the LOCK prefix on read-modify-write instruction with the mis-aligned data. To satisfy ISA guarantees in this case, the CPU has to either take more than one cache line for exclusive ownership in MESI-like cache coherence protocol, or exercise so called bus lock ensuring global cache ownership. Either option has very high cost and causes observable detrimental effects on other processes and virtual machines executing on the same physical host.

Since some time Intel provides a control for the lock operations that need to span more than one cache line (split locks). Turning the control on causes split locks to generate the same #AC exception as done by the AC flag, but only for the split locks, instead of all unaligned accesses.

The feature is controlled by the platform MSR and is per-CPU global, which precludes making the MSR directly available to userspace. The new sysarch(2) operation I386_SET_SPLITLOCK was developed that enables the control for the calling thread. The control is part of the machine state maintained on the context switch.

The intent is mainly to assist in catching bugs where improperly alignment locking structures are created, unlike Linux, which uses the feature to artificially penalize such processes by slowing them down. If the program code modifications are not possible, users and administrators can LD_PRELOAD a trivial shared object that turns the control on.

Sponsor: The FreeBSD Foundation

Links:
Commit adding aq(4) driver snapshot URL: https://cgit.freebsd.org/src/commit/?id=493d26c58e732dcfcdd87993ef71880adfe9d0cb
Commit adding aq(4) build infrastructure URL: https://cgit.freebsd.org/src/commit/?id=75177aebf0397af36b1f28f6b6e64207ec3d8188
Commit adding Atlantic 2 (AQC113) support URL: https://cgit.freebsd.org/src/commit/?id=dc5c0fc51cf47d6dfc737343e06805db294258e9

Contact: Ed Maste <emaste@freebsd.org>
Contact: Nick Price <nprice@freebsd.org>

Aquantia (now Marvell) AQtion devices are multi-gigabit PCIe Ethernet controllers supporting speeds up to 10 Gb/s. They are found on workstation and desktop motherboards, and add-in NICs.

Aquantia published a FreeBSD driver for its first-generation "Atlantic" controllers, but it was unmaintained for some time. FreeBSD developers contributed some fixes to the vendor’s repository, but several pull requests were never addressed. The driver was available in the ports collection as net/aquantia-atlantic-kmod, with some additional patches, but it was not part of the base system and lacked support for newer devices.

Ed Maste imported a snapshot of the vendor driver, applied patches from unmerged pull requests and the port, wrote an aq(4) man page, and connected it to the build.

Since then, Nick Price added support for the second-generation Atlantic 2 (AQC113) controllers, and has made extensive fixes and improvements throughout the driver. These include enabling jumbo frames, software LRO, and suspend/resume; correcting RSS queue distribution and honouring the kernel RSS policy; expanding and fixing checksum and VLAN offloads and VLAN/multicast filtering, hardening the attach, detach, reset, interrupt and RX/TX paths; handling PHY thermal shutdown; and improving diagnostics and link-state reporting.

The driver is available in -CURRENT snapshot images, and has been MFC’d to stable/15 to be included in FreeBSD 15.2.

Sponsor: The FreeBSD Foundation (Ed’s work)

Links:
Banana Pi on the FreeBSD Wiki URL: https://wiki.freebsd.org/arm/Bananapi

Contact: Martin Filla <freebsd@sysctl.cz>

This project adds FreeBSD support for three Banana Pi router boards: the BPI-R2 (MediaTek MT7623, armv7), the BPI-R64 (MediaTek MT7622, arm64) and the BPI-R2 Pro (Rockchip RK3568, arm64).

Links:
rocm-systems fork with FreeBSD support URL: https://github.com/Yohello1/rocm-systems/tree/rebase-systems
drm-kmod fork with partial amdkfd support URL: https://github.com/Yohello1/drm-kmod-rocm/tree/super-special

Contact: Sourojeet Adhikari <siri@racha.ca>

ROCm is AMD’s compute platform, which is the set of libraries, drivers, and tooling used to program their AI accelerators, and/or GPUs. On FreeBSD there are only a few ways to run compute workloads (AI/ML, graphics, and so on) on the GPU, and to my knowledge those are Vulkan and OpenGL. Both are fine for graphics, and sometimes machine learning too, but a lot of workloads are just not well suited to them, and end up being done in ROCm or CUDA instead, since those give the developer a lot more control over how the task is actually executed.

So I have been slowly porting the ROCm toolchain over to FreeBSD, which would let the AI accelerator ecosystem run natively here.

Most of my time recently has been spent getting rocr-runtime working from my rocm-systems fork, whilst upstreaming the changes needed in the FreeBSD kernel. Once the kernel side is done, I can merge the amdkfd code into drm-kmod (after a lot of cleaning up), and from there it is mostly a matter of time getting the remaining pieces of rocr-runtime running.

Links:
Launching FreeBSD/EC2 desktop AMIs URL: https://www.daemonology.net/blog/2026-09-24-Launching-FreeBSD-EC2-desktop-AMIs.html

Contact: Colin Percival <cperciva@FreeBSD.org>

FreeBSD is available on both amd64 (Intel and AMD) and arm64 (Graviton) EC2 instances.

A fix to ena(4) taskqueue NUMA binding has been applied, resulting in significant improvements in network throughput on c8gn.48xlarge systems starting with 14.5-RELEASE.

EC2 now supports automatically growing filesystems when EBS volumes are expanded; this is enabled by default in 16.0-CURRENT and will be available as a non-default option in 15.2-RELEASE.

The ebsnvme tool which ships in EC2 images now supports the "ebsnvme stats" command, compatible with Amazon Linux.

A new "desktop" flavour of AMI is now available for FreeBSD 15, which uses xrdp to expose a KDE environment.

Sponsor: Amazon
Sponsor: https://www.patreon.com/cperciva

Links:
Documentation Project Portal URL: https://docs.freebsd.org/
Documentation Project Primer for New Contributors URL: https://docs.freebsd.org/en/books/fdp-primer/
Documentation Engineering Team URL: https://www.freebsd.org/administration/#t-doceng

Contact: Documentation Engineering Team <doceng@FreeBSD.org>

The Documentation Engineering Team is responsible for defining and following up documentation goals for the committers in the Documentation Project. The doceng team charter describes the duties and responsibilities of the Documentation Engineering Team in greater detail.

This quarter in the Documentation Project, in addition to routine maintenance, several projects have come to fruition or were underway:

This quarter, Vladlen Popolitov <vladlen@FreeBSD.org> was promoted to a doc commit bit. No other commit bits have been granted or taken in for safekeeping during this quarter.

Links:
The FreeBSD Official Website in Russian URL: https://www.freebsd.org/ru/
FAQ URL: https://docs.freebsd.org/ru/books/faq/
The FreeBSD Russian Documentation Project site URL: https://github.com/freebsd-doc-ru/freebsd-doc/discussions

Contact: Andrey Zakhvatov <andy@FreeBSD.org>
Contact: Vladlen Popolitov <vladlen@FreeBSD.org>

The FreeBSD Russian Documentation Project’s current goal is to provide up-to-date Russian translations of the most important parts of the FreeBSD documentation (FAQ, Handbook, website content). It is essential to support Russian-speaking users with high-quality official technical materials and to increase the adoption of the operating system worldwide. We hope this initiative will gain support within the Russian-speaking FreeBSD community and lead to an increase in translated materials.

During the last quarter:

Plan for the next quarter:

Check the official translation guide if you would like to help.

We would appreciate your assistance:

Links:
FreshPorts URL: https://www.freshports.org/
FreshPorts test site, with translations URL: https://test.freshports.org/
How to translate FreshPorts URL: https://github.com/FreshPorts/freshports/tree/main/locale
Translation support issue URL: https://github.com/FreshPorts/freshports/issues/678

Contact: Dan Langille <dvl@FreeBSD.org>

FreshPorts, and its sister site, FreshSource, have reported upon FreeBSD commits for over 25 years. They cover all commits, but their primary focus is ports.

FreshPorts tracks the commits and extracts data from the port Makefiles to create a database of information useful to both port developers and port users. For example, https://www.freshports.org/security/acme.sh/ shows the history of this port, back to its creation in May 2017.

Until now, the website was available only in English.

Links:
https://github.com/Martinfx/FreeBSD-Ports/tree/master/brave

Contact: Martin Filla <freebsd@sysctl.cz>

Links:
freebsd-dockerbox Github URL: https://github.com/leafoliage/freebsd-dockerbox
dockerbox-broker Github URL: https://github.com/leafoliage/dockerbox-broker
freebsd-dockerbox-debian Github URL: https://github.com/leafoliage/freebsd-dockerbox-debian

Contact: Chun-Cheng Yeh <leafoliage@FreeBSD.org>

Dockerbox is a virtualized Docker daemon. Although the Docker daemon is not natively available on FreeBSD, Dockerbox runs it inside a Debian Bhyve virtual machine to provide access to it.

Links:
KDE/FreeBSD initiative URL: https://freebsd.kde.org/
FreeBSD — KDE Community Wiki URL: https://community.kde.org/FreeBSD

Contact: KDE on FreeBSD Mailing List <kde@FreeBSD.org>

The KDE on FreeBSD project packages CMake, Qt, and software from the KDE Community, for the FreeBSD ports tree. The software includes a full desktop environment called KDE Plasma (for both X11 and Wayland) and hundreds of applications that can be used on any FreeBSD machine. The KDE team is part of desktop@, building the software stack to make FreeBSD beautiful and usable as a daily driver graphical desktop workstation.

Links:
Project description URL: https://freebsdfoundation.org/project/improving-openjdk-on-freebsd/
Project repository URL: https://github.com/freebsd/openjdk
Upstream BSD port repo URL: https://github.com/openjdk/bsd-port

Contact:
Harald Eilertsen <haraldei@FreeBSD.org>
FreeBSD Java mailing list <freebsd-java@lists.freebsd.org>

The goal of this project is to improve OpenJDK support for FreeBSD/amd64 and FreeBSD/arm64.

Java is an important runtime environment for many high performance, critical enterprise systems. Making sure Java based applications run correctly and efficiently on FreeBSD is important to ensure that FreeBSD will continue to be a viable and attractive platform for enterprises, as well as businesses and organizations of all sizes.

This quarter, a few rather big, invasive features have been merged upstream (JEP 401: Value Objects and JEP 539: Strict Field Initialization), meaning that it has been difficult to get reviews and acceptance for our changes in this period. We have spent the time on fixing issues with the BSD port, as well as keeping it up to date with the upstream changes as they have appeared.

The following fixes/improvements have been done in this quarter:

Sponsor: The FreeBSD Foundation

Links:
sysutils/slurm-wlm URL: https://cgit.freebsd.org/ports/tree/sysutils/slurm-wlm/
net/ucx URL: https://cgit.freebsd.org/ports/tree/net/ucx/
net/openmpi URL: https://cgit.freebsd.org/ports/tree/net/openmpi/
benchmarks/py-reframe-hpc URL: https://cgit.freebsd.org/ports/tree/benchmarks/py-reframe-hpc/
sysutils/py-clustershell URL: https://cgit.freebsd.org/ports/tree/sysutils/py-clustershell/
SchedMD bug 25911: proctrack/freebsd-reaper URL: https://bugs.schedmd.com/show_bug.cgi?id=25911
SchedMD bug 25912: configless OS-specific Include files URL: https://bugs.schedmd.com/show_bug.cgi?id=25912
openucx/ucx#11549: UCS/SYS portability fixes for non-Linux platforms URL: https://github.com/openucx/ucx/pull/11549
hpc/mpifileutils#664: Portability fixes for FreeBSD/non-Linux builds URL: https://github.com/hpc/mpifileutils/pull/664

Contact: Generic Rikka <rikka.goering@outlook.de>

This report continues the FreeBSD HPC Ports Modernization initiative, which aims to make FreeBSD a practical and maintainable platform for modern high-performance computing (HPC) software stacks. Previous quarters focused on bringing the Slurm, PMIx, PRRTE and UCX stack up to date and filling gaps in the surrounding ecosystem. This quarter’s work centered on three things: keeping the scheduler and communication libraries current (including security fixes), deepening FreeBSD-specific runtime support in UCX and enabling the Open MPI/UCX combination, and taking the first FreeBSD-native Slurm features upstream to SchedMD.

Links:
libvirt: Bhyve driver URL: https://libvirt.org/drvbhyve.html

Contact: Roman Bogorodskiy <novel@FreeBSD.org>