FreeBSD Status Report First Quarter 2026

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.4-RELEASE announcement URL: https://www.freebsd.org/releases/14.4R/announce/
FreeBSD 15.1-RELEASE schedule URL: https://www.freebsd.org/releases/15.1R/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.4-RELEASE, leading to the official RELEASE build and announcement in March. Planning has started for the upcoming 15.1-RELEASE, which is due to arrive in June.

The Team gained four new members, Sergio Carlavilla Delgado, Craig Leres, Vladlen Popolitov, and Alexander Ziaee, and two members have departed: Jake Freeland and Mahdi Mokhtari. We thank them for their contributions.

The Release Engineering Team continued providing weekly development snapshot builds for the main, stable/15, stable/14, and stable/13 branches. Note that the weekly snapshot builds for stable/13 will end when that branch reaches its End-of-Life at the end of April.

Links:
About FreeBSD Ports URL:https://www.FreeBSD.org/ports/
Contributing to Ports URL: https://docs.freebsd.org/en/articles/contributing/#ports-contributing
Ports Management Team URL: https://www.freebsd.org/portmgr/
Ports Tarball URL: http://ftp.freebsd.org/pub/FreeBSD/ports/ports/

Contact: FreeBSD Ports Management Team <portmgr@FreeBSD.org>

The Ports Management Team is responsible for overseeing the overall direction of the Ports Tree, building packages, and personnel matters. Below is what happened in the last quarter.

During the last quarter, we welcomed Yusuf Yaman (nxjoseph), Kousuke Kannagi (mce), Piotr Smyrak (smyru), Laurent Chardon (laurent), and Kenneth Raplee (kenrap) as new ports committers, and said goodbye to one committer.

According to INDEX, there are currently 37,958 (up from 37,163) ports in the Ports Collection. There are currently about 2,710 (down from 3,428) open ports PRs, of which 798 (down from 821) are unassigned. The last quarter saw 8,970 (up from 8,738) commits by 166 (up from 156) committers on the main branch and 697 (down from 898) commits by 59 (down from 61) committers on the 2026Q1 branch.

The most active committers to main were:

A lot has happened in the ports tree in the last three months, an excerpt of the major software upgrades are:

During the last quarter, pkgmgr@ ran 29 exp-runs to test various base system changes and ports upgrades.

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: bugs.freebsd.org/

Contact: Bugmeister <bugmeister@FreeBSD.org>

The Bugmeister team is responsible for ensuring that the Problem Report software is in working order, entries are correctly categorised, and that there are no invalid entries.

We are ending the quarter with 9548 open PRs, creeping slightly upwards in every category from this time last year. We spent most of our time this quarter greeting new contributors before providing them with an account. We think this is going very nicely and has provided an increase in engagement and submission quality, but we do think we could use a few more people on the team.

We welcomed a new member of the Triage Team, Simon Wollwage, who has been lovingly going through the database, rebasing patches, and being kind to contributors. Many reports have been closed or had their underlying issues fixed from his efforts, and we thank him.

We finished updating documentation to request that proposed changes are sent as git format patches. This will save time, increase security, and properly convey author metadata. If we missed a spot, please let us know.

See also: https://wiki.freebsd.org/Bugzilla/SearchQueries

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 the 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 February and March the project has moved from planning into active delivery. Internal weekly coordination meetings are now in place, and the Foundation’s contracted security lead, Pierre Pronchery, has joined the FreeBSD Security Team to align the project work more closely with the FreeBSD Project’s existing security processes.

On the regulatory engagement front, the Foundation co-signed an Open Source Initiative letter to the European Commission supporting voluntary security attestations, contributed to Eclipse Foundation feedback on draft CRA guidance, and attended FOSDEM and FOSS Backstage to collaborate with other open source communities navigating the CRA.

Technical work on the SBOM toolchain is progressing well, with early automated SBOM generation now under testing. A public project repository has been created to track progress transparently, a community FAQ has been published, and a dedicated contact address is available for questions. Outreach to downstream manufacturers has also begun.

Links:
pkgbasify URL: https://github.com/FreeBSDFoundation/pkgbasify

Contact: Isaac Freund <ifreund@freebsdfoundation.org>

The pkgbasify script is used to convert non-pkgbase FreeBSD systems to pkgbase systems.

In the last quarter, I landed several improvements in upstream pkg, allowing pkgbasify to become both simpler and more robust. At the same time, the dependency of pkgbasify on the etcupdate database in /var/db/etcupdate/current can be now be eliminated, making pkgbasify much more flexible.

These improvements will be available to end users after the pkg 2.7 release.

Sponsor: The FreeBSD Foundation

Links:
Alpha-Omega — Linux Foundation Project URL: https://alpha-omega.dev
Alpha-Omega on GitHub URL: https://github.com/ossf/alpha-omega
FreeBSD Foundation URL: https://freebsdfoundation.org
Project repository from the FreeBSD Foundation URL: https://github.com/FreeBSDFoundation/alpha-omega-beach-cleaning

Contact: Pierre Pronchery <pierre@freebsdfoundation.org>

Alpha-Omega’s mission is to catalyze sustainable security improvements to critical open source projects and ecosystems. After a successful project with the FreeBSD Foundation in 2024 — auditing the bhyve hypervisor and the Capsicum sandboxing framework — Alpha-Omega has selected FreeBSD again, for the Alpha Omega Beach Cleaning project this time. This new grant consists in generally improving the security and maintenance of third-party software within the FreeBSD base system. The FreeBSD Foundation received the grant and has managed and executed the project. This project is officially completed as of March 30th, 2026.

After the previous report from 2025Q4, two major objectives have been identified:

Both objectives are nearing completion, and they were presented publicly at AsiaBSDCon 2026 in Taiwan, during the FreeBSD Developer Summit as well as during the conference’s Work-in-Progress session.

Monthly reporting has been submitted to alpha-omega and is available as before on GitHub for 2025 and for 2026.

Sponsor: Alpha-Omega, The FreeBSD Foundation

Links:
spdxtool: Add parameter for using URI as SPDX id URL: https://github.com/pkgconf/pkgconf/pull/484
spdxtool: Add cli parameter for changing SPDX id URL: https://github.com/pkgconf/pkgconf/pull/483
spdxtool: spdxtool: Add homepage handling URL: https://github.com/pkgconf/pkgconf/pull/475
spdxtool: Add source handling to SBOM URL: https://github.com/pkgconf/pkgconf/pull/474
spdxtool: Add support for copyright text URL: https://github.com/pkgconf/pkgconf/pull/473
spdxtool: Rework of License-tag SDPX expression evaluation URL: https://github.com/pkgconf/pkgconf/pull/461
Add some stricter compiler warnings and overcome new warnings URL: https://github.com/pkgconf/pkgconf/pull/450
libpkgconf/libpkgconf.h: Add printf-like attributes to functions URL: https://github.com/pkgconf/pkgconf/pull/447
spdxtool: Update variables that are const to const URL: https://github.com/pkgconf/pkgconf/pull/446
man/spdxtool.1: Add man page for spdxtool URL: https://github.com/pkgconf/pkgconf/pull/445
Added SPDX-License-Identifiers URL: https://cgit.freebsd.org/src/log/?qt=author&q=Tuukka+Pasanen
SPDX-License-Identifiers up-to review and waiting for upstreaming URL: https://github.com/freebsd/freebsd-src/compare/main…​illuusio:freebsd-src:update-spdx-licenses
Issue open for commenting and review: caesar: Add SPDX-License-Identifier tags URL: https://reviews.freebsd.org/D55461
.pc file for SBOM metadata (WIP) URL: https://github.com/illuusio/freebsd-src/tree/sbom-pkgconfig/release/sbom

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

The FreeBSD Software Bill of Materials (SBOM) project started in 2025 and continued in 2026. Work in 2026 has focused more on the EU Cyber Resilience Act (CRA), and the effort has shifted toward delivering a framework for FreeBSD source.

In the first quarter of 2026, SBOM work was delivered in three categories:

If you want to help with this effort:

Sponsor: The FreeBSD Foundation

Links:
Project URL URL: https://freebsdfoundation.github.io/freebsd-laptop-testing/
GitHub repository URL: https://github.com/FreeBSDFoundation/freebsd-laptop-testing

Contact: Shreeney Ajmeri <shreeney@freebsdfoundation.org>

The goal of this project is to create a community workflow for users of FreeBSD to easily test their laptops against, placing all tested laptops in a table, along with a ranking system to automatically deduce which laptops are currently the best for running FreeBSD on.

As part of the FreeBSD Foundation’s Laptop Support and Usability Project, this workflow will prove very useful for prospective users of FreeBSD, who want to test their laptops to see how well-supported they are. It also helps buyers who want to purchase a laptop that is known to be well-supported by FreeBSD.

The main goal is to consolidate all FreeBSD laptop compatibility information into one central knowledge base for the community to refer to.

During this quarter the following items were completed,

In addition, extensive testing took place during this quarter,

Other notes:

Sponsor: The FreeBSD Foundation

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 Sabato Siciliano <asiciliano@FreeBSD.org>

In the past, I developed several shell scripts with graphical interfaces to install and configure a complete desktop environment on my laptop. These interfaces allowed users to select their preferred options. One script in particular included GPU drivers, desktop environments, and tools for both laptops and desktop systems. These projects are still available in public online repositories, but they are now likely obsolete, as they have not been used or maintained for several years.

Recently, the FreeBSD Foundation launched the Laptop Support and Usability Project. One of the short-term goals 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 KDE Plasma graphical login screen.

To implement this feature, I reused one of my previous scripts as a proof of concept. It has been updated, simplified, and renamed to desktop. The script installs and configures GPU drivers, Xorg, KDE Plasma, and SDDM. Based on the feedback received, I introduced several improvements over the original version:

In the future, depending on user interest and feedback, support can be extended to additional desktop environments and tools.

One of the main challenges was the wide variety of supported GPUs. For this reason, I launched a call for testing, involving the community through a script to be executed on an already installed system. The feedback and suggestions received were very positive and valuable. Contributions are still welcome, especially for:

A version of the script was later adapted for integration into bsdinstall and into an installation ISO. After successful testing on both CURRENT and STABLE, a review has been submitted to add the desktop script to bsdinstall: D56167.

Sponsor: The FreeBSD Foundation

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

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.

During this quarter, there were many bugfixes and improvements to Bhyvemgr.

These are some highlights that were added:

Bhyvemgr supports aarch64 from 15.x to 16-CURRENT and amd64 from FreeBSD 14.x to 16-CURRENT. It can be compiled or installed from ports or packages with gtk2, qt5, or qt6 interface support.

People interested in helping or supporting the project are welcome.

Current version: 1.13.1

Sponsor: https://paypal.me/alonsocbsd

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

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.

At the end of this quarter, we made our first v0.1.0 release of Sylve, and at the time of writing this article, we are at v0.2.3.

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:
AppJail on GitHub URL: https://github.com/DtxdF/AppJail
AppScript on GitHub URL: https://github.com/DtxdF/appscript
x11appjail on GitHub URL: https://github.com/DtxdF/x11appjail

Contact: Jesús Daniel Colmenares Oviedo <dtxdf@FreeBSD.org>

AppJail is an open-source BSD-3 licensed framework entirely written in POSIX shell and C to create isolated, portable and easy to deploy environments using FreeBSD jails that behaves like an application.

AppScript is a very lightweight and easy-to-use tool for creating self-extracting executables.

OS-level virtualization is not as perfect as hardware-level virtualization: a vulnerability in a device not hidden within the jail could pose a risk to the host, but, if done correctly, it is much better than running an application directly from the host.

Jails are the implementation of OS-level virtualization for FreeBSD. With jails, many things can be easily restricted: limiting resources, restricting access to /dev devices, limiting the filesystem, restricting the network, and many other aspects. All transparently to the application running within the jail. However, one issue, specifically with X11 applications, is the lack of isolation. Users often misuse the xhost + trick to run an X11 application inside the jail and display the application on the host’s X server. This poses a security risk because, even though the X11 application runs inside the jail and even though it does so as an unprivileged process, it can obtain a great deal of information from the host. Therefore, a compromised application, one with a backdoor, or simply one that collects a lot of information for «telemetry purposes» could be a nightmare with this setup and, in the worst-case scenario, compromise the host.

A new command has recently been implemented in AppJail to solve this problem: appjail-x11(1). This command runs an application inside the jail but displays it on a new X server created by Xephyr, which is already authenticated with MIT-MAGIC-COOKIE-1. This is much simpler and lightweight than setting up an SSH server inside the jail, creating a key pair for this purpose, connecting to the jail, etc. However, this command is not limited to just that: you can resize the Xephyr window, and your DE/WM will be refreshed accordingly, as this command is capable of detecting such changes.

However, while much has been achieved with this command, the user must install a DE/WM and the application inside the jail, and perhaps install a custom .desktop file on the host. This can be automated using Makejails, and advanced users will be fine with that, since they love customizing everything, but for the average user (or even for me), what I wanted was to distribute applications so that users would not have to do anything more than simply run the application, and that is what x11appjail aims to solve.

x11appjail is a repository containing pre-made scripts for deploying certain X11 applications using appjail-x11, which automates the installation of the .desktop file, the icon, the creation of the jail via Makejails, and some reasonable default environment variables that can be easily modified at runtime. However, the repository actually exacerbates the usability issue: now the user has to clone and pull updates, which may be enough for some users, but what I wanted was reasonably good usability of the application and the ability to easily isolate it in a jail. Therefore, I wrote appscript, which creates SFX files in ELF format, and these are automatically created with each new release of that repository thanks to a GitHub workflow.

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

Links:
Daemonless URL: https://daemonless.io

Contact: Michael Johnson <ahze@ahze.net> Contact: Jesús Daniel Colmenares Oviedo <dtxdf@FreeBSD.org>

Daemonless is a collection of FreeBSD-native OCI images that run directly on the FreeBSD kernel. It combines the power and security of Jails with the modern container ecosystem—compatible with Podman, AppJail, or any OCI-compliant runtime. No Linux virtual machines or overhead required.

Features:

Our image fleet contains more than 60 images, ranging from media managers such as Radarr, Sonarr, Prowlarr, Lidarr, Readarr, Bazarr, and Jellyfin, to downloaders like SABnzbd and Transmission, and even infrastructure software such as nginx, Vaultwarden, Smokeping, and OpenSpeedTest. We even have a complete stack for Immich!

All of these images were created using https://daemonless.io/guides/dbuild/, the primary build engine for the Daemonless project, which has been recently ported. It provides a unified interface for building, testing, and publishing FreeBSD OCI container images, ensuring consistency between local development and CI/CD environments.

In addition to deploying OCI containers using Podman and Podman-Compose, it has recently become possible to use https://github.com/DtxdF/AppJail and https://github.com/DtxdF/director as alternatives, thanks to their OCI compatibility.

Links:

Kernel benchmark writeup URL: https://github.com/Humanoid-Human/fbsd-work/blob/main/kernel-benchmark.md
MAINTAINERS srcmgr thread URL: https://github.com/freebsd/srcmgr/issues/21
MAINTAINERS pull request URL: https://github.com/freebsd/freebsd-src/pull/2107
pkg to distribution set converter URL: https://github.com/Humanoid-Human/fbsd-work/pull/1

Contact: Trevor Xu <trevorxu5@gmail.com>

My work this term was split between three projects.

Links:
LLVM Meta Issue URL: https://github.com/llvm/llvm-project/issues/180061

Contact: Minsoo Choo <minsoochoo0122@proton.me>

Due to the licensing issue with GDB (GPLv3), FreeBSD has adopted LLVM, including LLDB, in its base system since FreeBSD 10.0. However, most kernel developers still rely on KGDB, a patched version of a recent GDB, to debug the kernel. This is partly a matter of personal preference (some find GDB’s command syntax more comfortable), but there are also practical reasons: LLDB lacks several features that KGDB provides (see below for details) and has insufficient support even in the base system. My work aims to achieve feature parity with KGDB by the end of April.

The improvements I have made so far are listed in the link above. Note that small bug fixes are not included in that list.

The following are not supported: i386, arm, powerpc32, powerpc64be, and mips*. FreeBSD 13 and earlier are also unsupported. The targeted LLVM version is 23, although this work may be backported to FreeBSD’s in-tree LLVM and MFCed to stable/14 and stable/15 after Dimitry Andric finishes his LLVM 21 MFV.

I started this work in late January, and it is projected to be complete by April. Beyond feature parity, there are further possible improvements, such as minidump2elf support and adding UUIDs to kernel and core dump ELF headers.

The biggest blocker for this project is a lack of reviewers knowledgeable in both FreeBSD internals and KGDB internals. If you have time, please provide feedback on my pull requests. Testers on non-x86 and non-arm64 machines would also be very welcome. If you find any issues, please file a bug and ping me on llvm/llvm-project.

Sponsor: The FreeBSD Foundation

Contact: Konstantin Belousov <kib@FreeBSD.org>

FreeBSD offered the Process Descriptors facility for long time. Its main use is in the Capsicum sandboxes where the handle is required to operate on an object, and process descriptor provided such handle. Other operating systems provide similar facility under the same name. The offered API was not complete, main lacking part being the pdwait(2) system call, the analog of wait(2) family, which operates on the process descriptor instead of the process id.

The described project added pdwait(2) call. Another important addition was the pdrfork(2) call, which provides the same fine-grained support for process copy construction as rfork(2), but also returns the process descriptor as the handle, like pdfork(2).

After pdwait and pdrfork addition, the natural extensions for the posix_spawn(3) facilities were possible. Now the posix_spawnattr_setprocdescp_np(3) attribute requests that posix_spawn(3) returned process descriptor. Another natural addition was posix_spawnattr_setexecfd_np(3) which specifies the executable image by file descriptor instead of the name.

Together, the newly added features make the process descriptor complete and allow the use of posix_spawn in the sandboxes.

Sponsor: The FreeBSD Foundation

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

I have been working on a dedicated driver for System76 laptops and it is now available on CURRENT.

So far, I have added the support for:

The only thing left is switching between dGPU and iGPU by the driver. However, it is possible to switch without driver assistance.

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

Contact: obiwac <obiwac@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.

Most revisions have now been committed at this point, including the new acpi_spmc driver and s2idle support. The only remaining things to land are USB4 suspend support and the s2idle loop (but that requires some more discussion and investigation). See revisions D52861 and D54410 respectively.

Many bugs have been fixed, but there still is an issue where the system will sometimes lock up a few seconds after resuming. This was narrowed down to the NVMe drive not waking correctly after being suspended — still requires further investigation.

Work on an Intel PMC driver has started: D54881 This already allows for reading residency in the deepest possible S0ix state on Intel CPUs.

Work has started on a new generic power management interface: D55508 This is needed as s2idle is not an ACPI power state, and the only (modern) mechanism for power transition requests is the ACPI ioctl interface. It has not yet landed because we might end up changing or even removing the distinction between sleep types and sleep state transitions.

Sponsor: The FreeBSD Foundation

Links:
Code for the initial prototype for saving the system image URL: https://github.com/OlCe2/freebsd-src/tree/oc-hibernate
Design document on the loader part of the resume process URL: https://hackmd.io/50ygFG3qSmqMOKytJMuOGw?both=

Contact: Olivier Certner <olce@FreeBSD.org>
Contact: Konstantin Belousov <kib@FreeBSD.org>

Work is ongoing to have FreeBSD support hibernate (suspend-to-disk), without BIOS/firmware assistance to save the current machine state, for amd64 UEFI-booted machines.

The first phase was to make a prototype that saves a system image, at the moment putting aside consistency matters, so that parallel work can start on an EFI application meant to restore and bootstrap the saved image (Konstantin Belousov is working on this part). This phase was completed in March. A significant refactoring, in particular of the underlying dump infrastructure, needs to occur before that experimental code can be committed.

The main next phase is to ensure consistency of the saved system image, so that the system is viable once restored. In a nutshell, the biggest constraint here is that we must ensure that no more I/O is in flight for several reasons, which consists in first ensuring that no more I/O requests can be created and then draining the existing requests. In particular, on-going DMA accesses could change memory while it is being saved, leading to out-of-date caching in the saved image. Also, if resuming fails (because of, e.g., some hardware consistency issue), I/O that did not reach stable storage would be lost, whereas application or filesystem code would expect them to be committed (loss of consistency). We have started identifying the subsystems that need attention and analyzing which changes are required in them (e.g., bus, GEOM, disk drivers).

The phase after is to determine how to finally save the system image without tainting the consistency, as this operation itself modifies kernel memory. A first high-level possibility is to take a snapshot of memory after ensuring stability, and then resume normal operation to save the pages in their state at the moment the snapshot was taken. There are several possible refinements, such as forefront or lazy copying, with different implementation strategies, and thus characteristics and requirements. Advantages of snapshotting include the ability to use regular kernel code to save the image, with all available transformations supported. Drawbacks are higher memory consumption, although that depends a lot on the chosen implementation strategy and seems to be mitigable for a large part, and possibly some complications at very low levels of the kernel. An alternative which is under study is not to snapshot, but instead ensure that sending the image to disk only modifies state that will be effectively reset on resume. This alternative requires implementation of selective suspend, but otherwise we expect that a large part of the existing dump-on-panic code would be reusable. We are currently digging into the different options to better understand their feasibility and the trade-offs involved.

Sponsor: The FreeBSD Foundation

Contact: ShengYi Hung <aokblast@FreeBSD.org>
Contact: Olivier Certner <olce@FreeBSD.org>

Collaborative Processor Performance Control (CPPC) is a standard introduced by ACPI to allow the OS to manage performance and, conversely, efficiency levels of CPUs thanks to an abstract performance scale in general uncorrelated to and more fine-grained than mere frequency levels. Intel and AMD have been providing CPU implementations in support of ACPI CPPC for several years now.

FreeBSD had been supporting enabling CPPC but only for Intel processors and allowing to manage a useful but very limited subset of its functionality, thanks to the hwpstate_intel(4) driver added in 2020. Hardware autonomous selection of the performance target depending on the workload is forcibly enabled, and only the main corresponding hardware tunable, called Efficiency/Performance Preference (EPP), is exported to the administrator via a sysctl(8) knob.

We have added support for AMD CPPC’s implementation in the existing hwpstate_amd(4) driver which, contrary to hwpstate_intel(4), so far managed only "regular" P-states. The driver exports 4 sysctl(8) knobs: Minimum performance, maximum performance, desired performance and EPP. Minimum, maximum and desired performances are values between 0 and 255, but only a sub-range may have an effect depending on the hardware. Initial values of minimum and maximum performances are set to the effective sub-range bounds as instructed by the platform (if available). The EPP control serves to express a bias towards efficiency or performance, and is a value between 0 (maximum performance preference) and 255 (maximum efficiency preference). The desired performance may be set to any value between minimum and maximum performance, or to the special value 0 to enable hardware autonomous selection of target performance by the hardware depending on the current workload. The minimum performance, maximum performance and EPP controls apply regardless of whether autonomous selection is enabled or a specific desired performance specified. Note that the effect of each combination of these values depend on the CPU model, and we have already been able to observe wildly different behaviors on a few ones. Therefore, you should expect to have to experiment to find the values adapted to your use cases on a given machine.

hwpstate_amd(4) is included by the GENERIC kernel (through cpufreq(4)) and uses CPPC if the CPUs support it unless explicitly instructed otherwise (through the machdep.hwpstate_amd_cppc_enable tunable). Consequently, in order to avoid performance regressions, for the time being we have decided to set the above-mentioned controls for maximum performance, as this is the default behavior for traditional P-state support and also that of any other cpufreq(4) driver except for hwpstate_intel(4) (which currently forces hardware autonomous selection and sets EPP to 0x80 (50%) by default). This may be revised later depending on whether we can reliably determine if the running computer is a laptop.

Next steps are:

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

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:
Support the MediaTek Wireless cards URL: https://github.com/FreeBSDFoundation/proj-laptop/issues/66
Support the Realtek Wireless cards URL: https://github.com/FreeBSDFoundation/proj-laptop/issues/99

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: Tom Jones <thj@FreeBSD.org>

The Jumbo Payload Option is an IPv6 extension header intended to support packet sizes in excess of 65,735 octets. FreeBSD gained Jumbo Payload support from the KAME project, but not real networks ever carried support.

As part of modernising the IPv6 stack Jumbo support has been removed. As far as we can tell it has never been possible to use this support with a FreeBSD host.

Sponsor: The FreeBSD Foundation

Links:
Add Support for Geneve (RFC8926) URL: https://reviews.freebsd.org/D54172

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

Since the last report, I have broken the GENEVE implementation down into many smaller revisions to make it easier to review:

You can help to speed up the process by reviewing and providing feedback on phabricator.

Links:
drm-kmod: Build and run on ARM64 with 16.0-CURRENT URL: https://github.com/freebsd/drm-kmod/pull/402

Contact: Dmitry Salychev <dsl@FreeBSD.org>

I have successfully built and run graphics/drm-66-kmod with those patches on my Honeycomb LX2 with Radeon RX 460. With these patches 6.6-lts could be a substitute for anyone who relied upon retired graphics/drm-510-kmod.

Links:
Wiki URL: https://wiki.freebsd.org/arm/Bananapi

Contact: Martin Filla <freebsd@sysctl.cz>

Links:
Bug 292006 - dpni doesn’t behave properly in a bridge URL: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=292006
dpaa2: Setup interface caps on attach URL: https://reviews.freebsd.org/D53436
dpnaa2: announce transmit checksum support URL: https://reviews.freebsd.org/D54809
dpaa2: Perform bus_dma pre-write sync before enqueue operation URL: https://reviews.freebsd.org/D56144
dpaa2: dpaa2_ni_rx() RX checksum EN/ERR information for L3/4 URL: https://reviews.freebsd.org/D55320
dpaa2: Extract frame-specific routines to dpaa2_frame.[h,c] URL: https://reviews.freebsd.org/D56315
dpaa2: Extract checksum statuses on ingress URL: https://reviews.freebsd.org/D56383
dpaa2: ni: add more stats and link information URL: https://reviews.freebsd.org/D55321

Contact: Michael Tuexen <tuexen@FreeBSD.org>
Contact: Bjoern A. Zeeb <bz@FreeBSD.org>
Contact: Dmitry Salychev <dsl@FreeBSD.org>

Links:
Intel FRED specification before SDM URL: https://www.intel.com/content/www/us/en/content-details/819481/flexible-return-and-event-delivery-fred-specification.html + D55829 amd64: FRED support URL: https://reviews.freebsd.org/D55829

Contact: Konstantin Belousov <kib@FreeBSD.org>

Support for FRED AKA Flexible Return and Event Delivery feature of the very modern amd64 platform was implemented. FRED is the complete revamp of the hardware interface to report exceptions, interrupts, and system calls to the operating system, and the way operating system returns control from the handler to the interrupted code. The goal for designing FRED was to get rid of the layers of compatibility features and bugs that accumulated in the existing way, let us call it IDT based event delivery.

FRED specification is now included into the Intel SDM revision 90. AMD seems to be committed to provide FRED on some future implementations.

As such, FRED support requires the new code path for event handlers. The nice structuring of the FRED allows to have minimal assembly trampolines there, moving most of the dispatch to the C code.

The implementation of the FRED handler was relatively simple, and required much less time than I initially thought. It shows how good and natural the proposed interface is.

The testing so far was only done on the Simics emulator. FRED should be supported by the newly released Intel Panther Lake CPUs, but I do not have access to the real hardware.

Sponsor: The FreeBSD Foundation

Contact: Tom Jones <thj@FreeBSD.org>

The Allwinner H616 family of devices (H616, H616 and H700) are a series of small, but powerful SOCs with powerful media support. These are found in a number of TV Boxes, handheld devices and single board computers.

FreeBSD now has support for most peripherals and has been tested with the Orange Pi 2. There is a yet unknown issue with the Ethernet controller, but this is under investigation. Graphics support requires drm and this has not yet been explored. The video device is not support on u-boot or Linux as a framebuffer console.

Sponsor: The FreeBSD Foundation

Links:
FreeBSD 15.0-RELEASE AMIs URL: https://www.freebsd.org/releases/15.0R/ec2-ami-ids/release/

Contact: Colin Percival <cperciva@FreeBSD.org>

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

A list of EC2 AMIs for FreeBSD 15.0-RELEASE has been added to the FreeBSD website. This page includes javascript to allow the list to be filtered by region, architecture, flavour, and root filesystem.

A process is now in place for publishing updated EC2 AMIs in response to security advisories; we now have FreeBSD 15.0-RELEASE-p5 AMIs and anticipate typically having updated AMIs in place within a few hours of advisories being published. The AMI IDs for these are published via the SSM Parameter Store and the FreeBSD website. At present there is no mechanism in place for building updated AMIs for 14.x releases.

An issue causing the ena(4) driver’s I/O interrupts to all land on CPU 0 on arm64 systems has been fixed in main. The fix should be present in 15.1-RELEASE (June) and 14.5-RELEASE (September).

An issue causing the ena(4) driver to not attach when FreeBSD boots on r8i.96xlarge instances has been fixed in main. The fix is expected to be present in 15.1-RELEASE (June) and 14.5-RELEASE (September).

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

Links:
STACKIT URL: https://stackit.com/
STACKIT CLI URL: https://github.com/stackitcloud/stackit-cli

Contact: Robert Gogolok <gogolok@gmail.com>

I am working to ensure FreeBSD is a first-class platform for managing resources on STACKIT, the sovereign European cloud. The goal is to provide the BSD community with native, reliable access to STACKIT’s IaaS and PaaS tools.

Native Binaries: In addition to the existing sysutils/stackit port, native FreeBSD binaries (amd64/arm64) are now included in every official upstream release.

Upstream Contributions:

Future Work:

Links:
Cloud Native Buildpacks (CNBs) URL: https://buildpacks.io/
GitHub Buildpacks repository URL: https://github.com/buildpacks/pack

Contact: Robert Gogolok <gogolok@gmail.com>

Cloud Native Buildpacks (CNBs) transform application source code into container images. Those images can run on any cloud. With buildpacks, organizations can concentrate the knowledge of container build best practices within a specialized team, instead of having application developers across the organization individually maintain their own Dockerfiles.

Since the last report in 2025Q1, the project has transitioned from experimental support to official binary availability:

The next steps focus on lowering the barrier to entry for developers and improving the automation of the FreeBSD build path:

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 with translating the following materials:

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@ and multimedia@ teams, building the software stack to make FreeBSD beautiful and usable as a daily driver graphical desktop workstation.

Links:
GCC Project URL: https://gcc.gnu.org/
GCC 13 release series URL: https://gcc.gnu.org/gcc-13/
GCC 14 release series URL: https://gcc.gnu.org/gcc-14/
GCC 15 release series URL: https://gcc.gnu.org/gcc-15/
GCC 16 release series URL: https://gcc.gnu.org/gcc-16/

Contact: Lorenzo Salvadore <salvadore@FreeBSD.org>

This quarter we have three main pieces of news.

In January we investigated why GCC 16 weekly snapshots stopped compiling since the last snapshot of November. It took many eyes to understand what happened, but eventually the problem was understood and a fix was committed upstream in February. The details can be found in the upstream bug report. Thanks to all people who helped, in particular to Mark Millard and Dimitry Andric.

At the moment lang/gcc16-devel does not build on arm64. Unfortunately I have not found the time to really look into this yet, but I hope to be able to do it soon. PR 294062 is the bug report that tracks the issue.

The process to get GCC_DEFAULT=15 has started. The GCC_DEFAULT=14 update is still recent and GCC 14 is actively supported, so there is no hurry to get this completed; but since those updates tend to be long I have already started it. Thus this is not my top priority at the moment: it is is where I put my energy when I have spare cycles, for now.

Links:
Valgrind Home Page URL: https://www.valgrind.org/
Valgrind News URL: https://www.valgrind.org/docs/manual/dist.news.html

Contact: Paul Floyd <pjfloyd@wanadoo.fr>

When FreeBSD 14.4-RELEASE came out and all went smoothly I thought that there would be little to say for this quarterly status report. Then I started using a couple of 16.0-CURRENT machines that are part of the GCC server farm. There I saw several issues. At first there were many more failures than I would normally expect. A bit later the servers were updated and Valgrind broke quite badly, asserting early on in start up. Some of these issues were the usual high maintenance expected with Valgrind. A new Helgrind suppression was required for internal locks used by pthread_create. The servers were built and installed from source which affects the error callstacks occasionally. The Valgrind regression tests are quite sensitive to that kind of change and some extra filtering was required. The asserts were caused by incorrect assumptions in Valgrind that are used when the tool reads its own binary, mainly to enable it to print its own callstack if there is a crash. The final problem was caused by a change in the way that library split debug files files are produced.

Overall, this is more of a stabilization release. There are relatively few new features.

Valgrind 3.27 is due out at the end of April 2026 and devel/valgrind will be updated shortly after that.

Here is a list of bugfixes since my last report, Q3 2025.

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.

In this quarter the following issues/milestones were reached:

Other notes:

Sponsor: The FreeBSD Foundation

Links: Issue 272855 URL: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=272855 Sheet tracking Work in Progress URL: https://docs.google.com/spreadsheets/d/17hmRQ0ShY4SHHVEkQBVxqK2G88fPZLriTzO26zXdjC4/edit?usp=sharing

Contact: Ronald Klop <ronald@FreeBSD.org>

Having a vivid Java environment is useful for all kinds of applications of FreeBSD.

The default JAVA_VERSION in FreeBSD ports is changed from 8 to 21 on February 26th. This was a major step in versions. So quite some work was involved. This is all done now.

All ports known to break were fixed and no regressions have been reported since. The 2026Q2 ports branch will be the first stable ports branch having OpenJDK 21 as the default Java version.

Link: Issue 293559 URL: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=293559

Contact: Ronald Klop <ronald@FreeBSD.org>

Java is an important environment for running some application on FreeBSD. The OpenJDK ports are actively maintained and up to date. Since October 2025 OpenJDK 25 LTS is available in the ports tree.

Building on the groundwork of moving ports to OpenJDK 21 the switch of JAVA_DEFAULT to 25 is a much smaller step. Most Java ports compile and run without changes. Only a handful of ports need some fixes, which is currently in progress.

The work is being tracked in PR 293559.

I think it is reasonable to have the ports in shape for the JAVA_VERSION=25 setting in the second quarter of 2026.

Plan: * An exp-run is requested * Check the last ports and create a PR or commit * Commit the PRs that are timing out on maintainer feedback * Maybe ask for another exp-run * If done, increase JAVA_VERSION

Links:
Wazuh URL: https://wazuh.com

Contact: José Alonso Cárdenas Márquez <acm@FreeBSD.org>
Contact: Jesús Daniel Colmenares Oviedo <dtxdf@FreeBSD.org>

Wazuh is a free and open source platform used for threat prevention, detection, and response. It is capable of protecting workloads across on-premises, virtualized, containerized, and cloud-based environments.

Wazuh solution consists of an endpoint security agent, deployed to the monitored systems, and a management server, which collects and analyzes data gathered by the agents. Besides, Wazuh has been fully integrated with the Elastic Stack or OpenSearch Stack, providing a search engine and data visualization tool that allows users to navigate through their security alerts.

A lot has happened this quarter. Numerous improvements and bug fixes to enhance FreeBSD’s support with this excellent XDR/SIEM and security platform.

Makejails for Wazuh has been improved and now mimics the official Dockerfiles, so users familiar with it can easily deploy all Wazuh components using AppJail and Director:

This also adds cluster-mode infrastructure for Makejails.

Vulnerability detection is not yet implemented in FreeBSD, but Serpico has been developed to address this deficiency. Serpico is a security scanner for FreeBSD packages and releases that compares versions against a list of versions marked as vulnerable and displays vulnerability information in a compact JSON format for easy analysis with other security tools. The package includes rules for Wazuh and a dashboard that can be easily installed via the web-UI or the OpenSearch Dashboards API.

Current version: 4.14.3

Links:
sysutils/slurm-wlm URL: https://cgit.freebsd.org/ports/tree/sysutils/slurm-wlm/
net/pmix URL: https://cgit.freebsd.org/ports/tree/net/pmix/
net/prrte URL: https://cgit.freebsd.org/ports/tree/net/prrte/
net/openmpi URL: https://cgit.freebsd.org/ports/tree/net/openmpi/
net/ucx URL: https://cgit.freebsd.org/ports/tree/net/ucx/
benchmarks/py-reframe-hpc URL: https://cgit.freebsd.org/ports/tree/benchmarks/py-reframe-hpc/
sysutils/mpifileutils URL: https://cgit.freebsd.org/ports/tree/sysutils/mpifileutils/

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

This report continues the ongoing FreeBSD HPC Ports Modernization initiative, which aims to make FreeBSD a practical and maintainable platform for modern high-performance computing (HPC) software stacks.

Previous work focused on updating the core scheduler and runtime stack by modernizing sysutils/slurm-wlm and introducing standalone ports for net/pmix and net/prrte. During this quarter the focus shifted toward expanding the surrounding HPC ecosystem, improving integration between components, and upstreaming portability fixes discovered during the porting process.

The long-term goal is to provide a coherent HPC software environment in the FreeBSD Ports Collection that resembles what users expect on Linux-based HPC systems while remaining maintainable within the FreeBSD ecosystem.

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

Contact: Roman Bogorodskiy <novel@FreeBSD.org>