FreeBSD Status Report Third Quarter 2025
Here is the third 2025 status report, with 36 entries.
As usual, reports publication is slow due to some important reports arriving
late. We are sorry about that, but most of us are volunteers and we do our
best.
Luckily, it seems that the number of volunteers is about to increase: last
quarter I have seen much interest among new community members in getting
involved in the FreeBSD Project. This will surely improve the efficiency of the
whole development, including status reporting.
Many new recruits approach us with the same question: "How do I start?". This
is not the place to give an answer to this question, but actually a guide has
been written precisely to reply to it. You can find it here. Moreover, it is
always good to remember that using FreeBSD, as much as possible, helps a lot:
use it as your daily driver, run your webservers on it, install it on your
virtual machines, support it when you contribute to existing software! And if
you find bugs, do not forget to report them.
Have a nice read!
Lorenzo Salvadore, on behalf of the Status Team.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
A rendered version of this report is available here:
https://www.freebsd.org/status/report-2025-07-2025-09/
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Table of Contents
• FreeBSD Team Reports
□ FreeBSD Core Team
□ FreeBSD Foundation
□ FreeBSD Release Engineering Team
□ Ports Collection
• Projects
□ Framework Laptop support
□ Infrastructure Modernization
□ Alpha-Omega Beach Cleaning project
□ STA Work Package C: CI/CD Automation
□ Support for installing pkgbase systems
□ Sylve — A Unified System Management Platform for FreeBSD
□ FreeBSD Git Weekly
□ July 2025 FreeBSD Hackathon in Berlin, Germany
• Userland
□ ACPI Lua Bindings
□ Geomman Release
□ Sockstat UI Improvements
□ Process Credentials' Groups-Related Changes in FreeBSD 15
□ The Gallant Console Font got Supercharged
• Kernel
□ Audio Stack Improvements
□ DRM drivers
□ DRM Drivers Slowdowns and Freezes Fixes
□ LinuxKPI 802.11 and Native Wireless Update
□ mac_do(4) and mdo(1) Improvements
□ Suspend/Resume Improvement
□ USB Kernel Debugging Improvements
• Architectures
□ FreeBSD Driver Development for BananaPi-R64
• Cloud
□ Improvements for nuageinit
• Documentation
□ Documentation Engineering Team
□ The FreeBSD Russian Documentation Project
• Ports
□ A bhyve management GUI written in Freepascal/Lazarus
□ Container orchestration: Overlord, Director, AppJail and cloud-init
□ Improve libvirt support for bhyve hypervisor
□ Improve OpenJDK on FreeBSD
□ KDE on FreeBSD
□ GCC on FreeBSD
□ Valgrind: preparing for 15.0-RELEASE
□ A new Wi-Fi management utility: wutil
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
FreeBSD Team Reports
Entries from the various official and semi-official teams, as found in the
Administration Page.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
FreeBSD Core Team
Contact: FreeBSD Core Team <core@FreeBSD.org>
The FreeBSD Core Team is the governing body of FreeBSD.
Completed Items
Core completed the following items:
• EuroBSDCon core session
□ dch, glebius, hrs, rene were present at the conference.
□ dch had a talk with title "Core Team: Personal Perspective"
• Removing links to X/Twitter from the project website.
□ Core received a question if it is OK to remove links to X/Twitter from
the project website.
□ As the handle is not being used, core thinks this is fine.
□ The Project still needs to control the handle to avoid abuse by others.
□ The link can be re-added if someone in the project or Foundation can
use those SNS accounts well.
• Privacy-friendly web analytics, proposed by the Foundation.
□ An idea is to compare traffic flows between freebsd.org and
freebsdfoundation.org
□ Collaborated with doceng and deployed.
• Core and the FreeBSD Foundation were working on publishing the 2025 edition
of the Community survey result.
Work in Progress
Core is currently working on the following items:
• Core is creating a working group to restructure doceng.
• Committer mentorship guideline/rule
□ Brought up by inquirers from the developers.
□ Core idendified there are some existing documentations but should ask
doceng/portmgr/srcmgr for more input.
• Core election and term changes
□ From the feedback of the community, the preferred way is staggered core
terms.
□ One idea is to rate half of core every year instead of rotating
possibly. all of core every two years, so that in-progress work and
experience do not get lost.
□ Some developers have strong ideas about this (like rotating a third of
core each year instead of all of core every two years) and would like
to be involved.
□ We need to have the bylaws changed for this, the standard is high.
□ There are suggestions from the community for we just change the bylaws
as core does not legally represent anybody. Is that really a good idea?
□ This discussed at core session at BSDCan developer summit 2025.
□ Core is continuously working on this toward to setup staggered core
terms.
• Project continuity
□ Brought up by an inquriy from a developer
□ We need (updated) documentation on how to rebuild the critical systems
to ensure business continuity of the FreeBSD Project. This encompasses
three aspects:
□ Our own project business continuity (loss of key personnel or
infrastructure)
□ Replication for end consumers of FreeBSD
□ How does our release engineering work, and which of the various teams
are impacted.
□ Currently too much knowledge depends on tribal memory, need to collect,
sort and documented.
□ An artifact of the STA work is that release documentation is written
(next to the releng article in doc repository). Some corner cases are
currently missing.
• Committer GECOS fields and pseudonyms
□ A question came from a developer about whether pseudonyms can be used
as committer names.
□ There is a higher concern about how to deal with any copyright issues.
□ Core however does not feel that using pseudonyms is endorsed as it
makes paperwork and restoring cluster access more difficult, and
suggests mentioning the advantages of using real names.
□ Another way pseudonyms could cause problems is when the identity is
shared, e.g. in case of a vendor commit bit, who will be the
spokesperson?
• AI policy
□ The Core Team is in the process of drafting a policy on using AI and
LLMs.
□ For this effort, it also plans to consult with other groups, such as
the Foundation's legal counsel and people in the Linux and other open
source communities who are working on related topics.
□ There are various questions about copyright, guaranteeing code
provenance, best practices and "common sense" by both developers and
external contributors, and what can and cannot be done with AI
(assisted) tools.
□ There have been many follow-up discussions after BSDCan and EuroBSDCon,
and core is organizing and summarizing them.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
FreeBSD Foundation
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.
OS Improvements
Throughout the quarter, there were 451 src, 71 ports, and 25 doc commits
sponsored by the FreeBSD Foundation.
Refer to the following report entries describing much of that committed
development work:
• Suspend/Resume Improvements
• LinuxKPI 802.11 and Native Wireless Update
• Audio Stack Improvements
• Improve OpenJDK on FreeBSD
• Sylve — A Unified System Management Platform for FreeBSD
• Support for Installing pkgbase Systems
• DRM drivers
• Alpha-Omega Beach Cleaning Project
• Improve libvirt Support for bhyve Hypervisor
• STA Work Package C: CI/CD Automation
• USB Kernel Debugging Improvements
• DRM Drivers Slowdowns and Freezes Fixes
• Process Credentials' Groups-Related Changes in FreeBSD 15
Other highlights include:
• Improved virtual memory scalability, allowing multiple processes to load
shared libraries in parallel.
• Greater UFS reliability on very large filesystems (with more than 2 billion
inodes).
• Support for systems with over 4 TB of RAM, including a reworked Kernel
Virtual Address (KVA) layout tailored for the 57-bit address space (LA57)
architecture.
• Kqueue inheritance across fork().
• A new safeguard (noshutdown) to help prevent accidental system shutdown.
• Simplified and more reliable filesystem rename operations.
• A fix for amd64 pmap panics under low-memory conditions.
• Numerous fixes for race conditions in timeout handling.
• A new EXTERROR(9) interface, standardizing how external applications can
report detailed error information.
The Foundation also continued to support two major initiatives: the Laptop
Support and Usability project (in collaboration with Quantum Leap Research) and
an infrastructure modernization project commissioned by the Sovereign Tech
Agency. For background on both efforts, see the 2025Q1 quarterly status report.
FreeBSD, under the management of the Foundation, participated in its 21st
consecutive Google Summer of Code (GSoC) program. All twelve projects were
successfully completed.
Four of those GSoC participants contributed report entries:
• ACPI Lua Bindings
• Sockstat UI Improvements
• Geomman Release
• mac_do(4) and mdo(1) Improvements
Advocacy
Advocacy work in the 3rd quarter of 2025 included representing FreeBSD at open
source events, producing more technical tutorials and working on the upcoming
November 2025 FreeBSD Vendor Summit. Take a look at just a few of the ways the
Foundation helped advocate for FreeBSD in Q3 of 2025:
• Sponsored and attended EuroBSDcon 2025, held in Zagreb, Croatia; September
25-28, 2025.
• Members of the Foundation team presented at the Open Source Summit, Europe,
August 25-27, 2025, Amsterdam, Netherlands.
• Planning continued for the November 2025 FreeBSD Vendor Summit, taking
place November 6-7, 2025 in San Jose, CA. Registration is open and the
schedule is available.
• Published the following blogs and videos to help to inform and educate the
community:
□ How To Install and Configure the Galene Video Meeting Server
□ An Introduction to FreeBSD's Periodic System
□ BSDCan 2025 trip reports:
☆ Mark Johnston
☆ Chuck Tuffli
□ From Minecraft to Markets: Java Hiding in Plain Sight
□ FreeBSD Jails are Simple and Easy
• Published the June/July 2025 and August 2025 FreeBSD Foundation
Newsletters.
• Released the April/May/June 2025 issue of the FreeBSD Journal with HTML
versions of the articles.
Continuous Integration and Workflow Improvement
The Foundation supports a full-time staff member dedicated to improving the
Project's continuous integration system and test infrastructure.
Legal/FreeBSD IP
The Foundation owns the FreeBSD trademarks, and it is our responsibility to
protect them. We also provide legal support for the core team to investigate
questions that arise.
Go to https://freebsdfoundation.org to find more about how we support FreeBSD
and how we can help you!
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
FreeBSD Release Engineering Team
Links:
FreeBSD 15.0-RELEASE schedule URL: https://www.freebsd.org/releases/15.0R/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 the first half of the 15.0-RELEASE cycle, aiming for the
official RELEASE build and announcement in December. Of note, this has involved
a significant amount of pkgbase-related work landing.
The Release Engineering Team continued providing weekly development snapshot
builds for the main, stable/14, and stable/13 branches.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Ports Collection
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: Tobias C. Berner <portmgr-secretary@FreeBSD.org>
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 Älven (alven@) and Tiago Gashiba (tiga@)
as new ports committers, and said goodbye to six committers. We also promoted
Dan Langille (dvl@) as a full portmgr member after successfully being on the
lurker program.
According to INDEX, there are currently 37,163 (up from 36,605) ports in the
Ports Collection. There are currently about 3,428 (up from 3,330) open ports
PRs, of which 821 are unassigned. The last quarter saw 8,738 (down from 10,924)
commits by 156 (down from 157) committers on the main branch and 898 (up from
770) commits by 61 (up from 56) committers on the 2025Q3 branch.
The most active committers to main were:
• 2348 sunpoet@FreeBSD.org
• 574 yuri@FreeBSD.org
• 409 vvd@FreeBSD.org
• 406 tagattie@FreeBSD.org
• 348 bofh@FreeBSD.org
• 223 jbeich@FreeBSD.org
• 161 fluffy@FreeBSD.org
• 153 eduardo@FreeBSD.org
• 147 alven@FreeBSD.org
• 143 arrowd@FreeBSD.org
A lot has happened in the ports tree in the last three months, an excerpt of
the major software upgrades are:
• pkg 2.3.1
• New USES: zig
• Default version of Lazarus switched to 4.2 (non-devel, non-aarch64)
• Default version of Perl switched to 5.42
• Chromium 140.0.7339.207
• Electron 37 and 38 added
• Firefox 143.0.3
• Firefox-esr 140.3.1
• KDE Applications 25.08.1
• KDE Frameworks 6.18.0
• KDE Plasma 6.4.5
• Ruby 3.4.6
• Rust 1.89.0
• SDL 3.2.22
During the last quarter, pkgmgr@ ran 12 exp-runs to test source code changes
and various ports upgrades.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Projects
Projects that span multiple categories, from the kernel and userspace to the
Ports Collection or external projects.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Framework Laptop support
Links:
Framework Laptop page on FreeBSD Wiki URL: https://wiki.freebsd.org/Laptops/Framework_Laptop/
Guide on installing and using FreeBSD on Framework systems URL:
https://github.com/FrameworkComputer/freebsd-on-framework
Tracking ticket: Framework Laptop: Feature support, bugs and improvements URL:
https://bugs.freebsd.org/262152
Contact: Daniel Schaefer <dhs@frame.work>
Contact: Li-Wen Hsu <lwhsu@FreeBSD.org>
Contact: ShengYi Hong <aokblast@FreeBSD.org>
Framework Computer Inc. is very supportive of the FreeBSD project in many ways,
including providing engineering samples to the Foundation for testing and
working on compatibility.
The Foundation continues to work on improving overall laptop support, and
Framework laptops are one of the target platforms for the Laptop Support and
Usability Project.
In the 2nd and 3rd quarter of 2025, there were two hackathons held in
Framework's Taipei office to test FreeBSD on the products newly released and in
development.
In April, we continued testing Framework Laptop 12 and Framework Desktop for
the support of the in-development 15.0, including the ethernet support, serial
console access, etc.
In September, we worked on testing Framework Laptop 16 AMD Ryzen AI 300 Series,
including the NVIDIA Graphics Module. ShengYi fixed the sound support for this
model.
Daniel has fixed fwupd on FreeBSD (#9220, #9221, #9223) and revived the FreeBSD
CI. This work is included in the fwupd 2.0.16 release.
Sponsor: The FreeBSD Foundation for Li-Wen and ShengYi's work
Sponsor: Framework Computer Inc for Daniel's work, hardware and space support
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Infrastructure Modernization
Contact: Ed Maste <emaste@FreeBSD.org>
Contact: Alice Sowerby <alice@freebsdfoundation.org>
The project started in Q3 of 2024 and was commissioned by the Sovereign Tech
Agency with a budget of $745,000, to be spent until the end of 2025. The main
goals are to improve security tools for the base system, ports, and packages,
update the project's infrastructure to speed up development, enhance build
security, and make it easier for new developers to get started.
For more detailed information and updates, please visit the new project
information repo.
Q3 update
All five work packages are in progress and will run until the end of December
2025, at which time the project will close.
Work Package A: Technical Debt Reduction
This work package is complete as of September 2025. The project successfully
ran alongside the setting up of the FreeBSD Project's Source Management team as
they created and embedded their new processes to make bug management easier and
more sustainable. The bug backlog dashboard they commissioned remains available
to help make the backlog easier to understand.
In August, we held a panel discussion at Open Source Summit Europe to share
this work with a wider audience. Two members of the Foundation project staff
(Alice Sowerby and Moin Rahman) were on the panel along with two
representatives from Bitergia who delivered the GrimoireLab implementation for
this project. (Members of the FreeBSD Project Source Management team were not
available to attend.)
The Foundation will continue to check in with the Source Management team
regularly until at least the end of 2025 to ensure that we understand the value
of the project going forward.
The scope was co-created with srcmgr@. Work items are as follows:
• Create a dashboard for the Source Management team to get a clearer picture
of the bug backlog, and how effectively it is being managed (e.g. Time to
First Attention for new bugs).
□ Output: https://grimoire.freebsd.org/
• Upgrade Bugzilla to a supported release to improve security and benefit
from new functionality.
□ Output: https://wiki.freebsd.org/Bugzilla/Roadmap
• Create a method for applying patches automatically.
□ Output: https://github.com/linimon/patchQA
• Creating upstream documentation for running GrimoireLab (bug dashboard) on
FreeBSD.
□ Output: https://github.com/chaoss/grimoirelab/blob/main/FreeBSD.md
Work Package B: Zero Trust Builds
This work package intends to improve tooling and processes to support Zero
Trust Builds of FreeBSD by extending the current components to enable the
project to build release artifacts (package sets, ISO images, etc.) without
requiring any special privilege.
The detailed scope was co-created with core@, srcmgr@, secteam@. Work items are
as follows:
• Must
□ No-root for all source release build cases/artifacts (complete)
□ Src artifacts to build reproducibly (in progress)
□ Formalize and document make world and release.sh (in review)
• Should
□ Remove privilege from orchestration tooling (not started)
□ Move build scripts into the public repository (in progress)
□ Address dependencies (in progress)
• Could
□ Environment Standardization (in progress)
□ Ports to build reproducibly (in progress)
□ CI to verify reproducibility (in progress)
□ Documentation to allow 3rd parties to confirm reproducibility (not
started)
Work Package C: CI/CD Automation
This work package intends to improve CI/CD automation to streamline software
delivery and operations for new and existing software by modernizing and
securitizing the existing CI/CD system and extending it to cover the third
party packages in the FreeBSD Ports Collection.
The detailed scope was co-created with core@, srcmgr@, portmgr@, doceng@ * Must
Improve quality of incoming commits (completed) Pre-merge CI (completed)
Environment Metadata (in progress) Extend CI to the Ports tree (in progress) CI
Threat Model (in progress) CI Management Process (in progress) Documentation
(not started) * Should 3rd-party Interoperability (in progress) Automated
analysis in tests (in progress) Test Case Management (in progress) * Could **
Granular Debugging (in progress)
Work Package D: Ports and Packages security improvements
This work package intends to modernize and extend security controls in the
FreeBSD Ports and Package Collection by: Migrating from our VuXML Vulnerability
Database to OSV or similar contemporary format; developing a package audit
backend and server to reliably fetch vulnerability data from global agency
databases in any format (JSON - NIST) and produce insight and; improving CI
tooling for FreeBSD Ports.
The detailed scope was co-created with core@, portmgr@, pkgmgr@, secteam@
• Must
□ New Database Format (in progress)
□ Set up 2+ Database Instances (not started)
□ Migrate Data from old to new database (in progress)
□ Add support for new format in pkg(8) (in progress)
□ Upstream engagement (in progress)
□ SBOM on demand (not started)
□ Document how to set up build and test targets (not started)
□ Integrate 3rd party test targets (not started)
□ Continuous Testing (not started)
• Could
□ Make CI artifacts available (not started)
Work Package E: SBOM improvements
This work package intends to improve existing, and implement new, tooling and
processes for FreeBSD Software Bill of Materials (SBOM) by implementing:
tooling to roll up the individual provenance data/markers from across the tree
into a higher-level view; developing tooling to parse/review/inspect the
FreeBSD source tree and produce a comprehensive/holistic report to act as a
SBOM for the full software stack and; extending pkg to enable this capability
for software installed from ports/packages.
The detailed scope was co-created with core@, portmgr@, pkgmgr@, secteam@,
releng@
• Must
□ Evaluate projects/solutions available in the wider ecosystem (in
progress)
□ Propose the target solution for SBOM (in progress)
□ Produce an SBOM in CI (e.g. weekly builds) (in progress)
□ Produce an SBOM as an artifact as part of the release process (in
progress)
□ SBOM artifact on demand (in progress)
□ Roll up existing data (in progress)
□ Record and explain decisions made (in progress)
• Could
□ Engage with other similar projects (in progress)
Commissioning body: Sovereign Tech Agency
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Alpha-Omega Beach Cleaning project
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 is managing
and executing the project.
The list of tasks has been determined as follows:
• Inventory of dependencies
• Security risk assessments
• Propose list of priorities
• Plan the respective actions
• Formalize code owners
• Integrate review methodologies
• Plan execution & coordination
• Final report
The first deliverables have been issued on the dedicated GitHub repository:
• Machine-readable database
• List of dependencies
• Security risk assessments
Help is welcome to complete the information collected, and to improve on any
other aspect of the project!
Finally, monthly reporting is submitted and available on GitHub.
Sponsor: Alpha-Omega, The FreeBSD Foundation
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
STA Work Package C: CI/CD Automation
Contact: Siva Mahadevan <smahadevan@freebsdfoundation.org>
In this quarter, as part of the infrastructure modernization work commissioned
by the Sovereign Tech Agency (STA), I have been working on the in-tree CI
Makefile targets. I also worked on bringing our CI test reports to a clean
state on our tier-1 architectures (amd64 and aarch64). This report is a
supplement to the overall STA status report and will describe the work done in
more detail.
tests/ci improvements
The tests/ci subdirectory in the src tree was introduced in commit: Add
preliminary in-tree CI infrastructure for developers by Moin Rahman and aims to
provide an easy way for developers to replicate the CI testing run by our
Jenkins cluster. In this quarter, the following improvements were made by the
team:
New functionality:
• tests/ci: run ci-full kyua tests in parallel
• tests/ci: Add KYUA_TEST_FILTERS to allow user to select specific tests
• tests/ci: Add CIENV variable
Bug fixes:
• tests/ci: Use suitable variable for qemu-user-static existence check
• tests/ci: fix race condition in bhyveload boot
• tests/ci: fix missing /usr/local/{sbin,bin} in freebsdci rc PATH
• tests/ci: Fix missing qemu devices
• tests/ci: Fix race condition with ci-extractmeta
• tests/ci: Fix wrong chflags target path in 'beforeclean' target
• tests/ci: Use QEMU blockdev declaration for all platforms
• tests/ci: Fix unescaped kld_list var in rc.conf
With these changes, a developer can run CI with these example commands as root:
# Fully parallel CI:
make ci
# Single-threaded CI
make PARALLEL_JOBS=1 ci
# Single-threaded CI, running a subset of the tests as described in kyua-test(1)
make PARALLEL_JOBS=1 KYUA_TEST_FILTERS='/path/to/testcase /path/to/another:testname1' ci
# Run smoke (boot) tests
make CITYPE=smoke ci
Test case management
Tinderbox has been reporting that our supported platforms are failing in CI
since a run from the last quarter. As the backlog grows larger, it becomes
harder for users and developers to notice a new failure and pin it to a
particular commit.
To complement the tests/ci CI/CD automation improvements, along with Bricoler
to help with more granular investigations, I worked on cleaning up the failing
test backlog on tier-1 architectures. The following patches and bug reports
were submitted as a result of this (still ongoing) work:
New bug reports filed to track failing or flaky tests:
• PR 288991: sys/netinet/output:output_raw_flowid_mpath_success
• PR 289096: lib/libexecinfo/sigtramp_test:test_backtrace_sigtramp
• PR 289165: usr.bin/limits/limits_test:cputime_soft_flag
• PR 289240: sys/netlink/netlink_socket:overflow
• PR 289239: sys/netpfil/pf/sctp:pfsync
• PR 289236: sys/kern/exterr_test:gettext_extended
• PR 289382: sys/netinet6/lpm6:lpm6_test1_success
• PR 289628: sys/netpfil/pf/nat:endpoint_independent_pass
• PR 289630: libexec/rc/rc_subr_test:wait_for_pids_progress
• PR 289237: sys/fs/fusefs/last_local_modify:main
• PR 289084: lib/libc/string/memcmp_test:{diff,neq}
• PR 289477: sys/netpfil/pf/
route_to:prefer_ipv6_nexthop_mixed_af_random_table_ipv4
• PR 289299: sys/netpfil/pf/rules_counter:keepcounters
• PR 289684: sys/netlink/test_snl:snl_parse_errmsg_capped
• PR 289146: sbin/ipfw/test_add_rule.py:TestAddRule::test_add_action
Unskip tests that are wrongly skipped in CI:
• tests/sys/netpfil: unskip tests that no longer need to be skipped
• tests/ci: Add missing kmods and pkgs to unskip tests
Test case metadata fixes:
• fix parallel execution of swapon tests
• cap_dns/tests/dns_test: mark tests as needing network access
• pfctl tests: use require.kmods instead of manual check for pf
• cap_net/net_test: require 'allow_network_access'
• tests/mac_portacl: enable is_exclusive for now
• tests/sys/mqueue: use require.kmods property instead of ad-hoc checks
• tests/sys/netlink: use require.kmods property instead of ad-hoc checks
• tests/sys/opencrypto: use require.kmods property instead of ad-hoc checks
• tests/sys/aio: use require.kmods property instead of ad-hoc checks
• tests/pf/ioctl: use require.kmods property instead of ad-hoc checks
• tests/sys/netmap: use require.kmods property instead of ad-hoc checks
• tests/sndstat: use require.kmods property instead of ad-hoc checks
• tests/socket_accf: use require.kmods property instead of ad-hoc checks
• tests/sys/net: use require.kmods property instead of ad-hoc checks
• tests/sys/netinet: use require.kmods property instead of ad-hoc checks
• tests/vmm_cred_jail: use require.kmods property instead of ad-hoc checks
mark tests as "expected fail" (xfail), currently WIP:
• atf_pytest: fix xfail detection from pytest report
Tooling (WIP)
To catch errors more quickly, instead of relying on Jenkins to update the test
report, I ran local CI multiple times daily. To help with this, I worked on
some tooling to speed up the testing/debugging cycles. I am maintaining the
following (currently uncommitted) tools:
• parallel CI runner built on top of tests/ci
• (VERY WIP) automated CI bug report/triage system
Sponsor: The FreeBSD Foundation
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Support for installing pkgbase systems
Contact: Isaac Freund <ifreund@freebsdfoundation.org>
The FreeBSD 15.0 snapshot installation images (disc1.iso, dvd1.iso) now include
offline pkgbase packages rather than traditional distribution tarballs. This
makes it possible to install a pkgbase system without an internet connection.
Patches to build FreeBSD 15.0 VM and cloud images as pkgbase systems are in
review and should land soon. Switching the VM and cloud images over to pkgbase
is the last major step needed to make pkgbase the default installation path for
FreeBSD 15.0.
Sponsor: The FreeBSD Foundation
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Sylve — A Unified System Management Platform for FreeBSD
Links:
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, inspired by
Proxmox. We aim to provide an integrated web interface for managing virtual
machines (via Bhyve), Jails, ZFS storage, networking, and firewalling. The
backend is implemented in Go, while the frontend uses SvelteKit with Tailwind
CSS and ShadCN UI components.
The project emphasizes a minimal system footprint, currently requiring only
sysutils/smartmontools, sysutils/tmux, libvirt, samba419, swtpm as runtime
dependencies.
Q3 Progress Highlights
Clustering
Sylve now supports simple clustering with a single-pane-of-glass (SPOG)
experience. This multi-master design, built on top of hashicorp/raft and
SQLite, allows users to manage multiple nodes from a single interface.
Networking
• Network Objects: Subnets, hosts, and MACs are now treated as first-class
objects. Users can create and reuse them across VMs, Jails, and switches.
• Manual Switches: Existing FreeBSD bridges can now be imported into Sylve
and managed as switches.
Storage
• A new file explorer has been introduced for managing each node's local
filesystem (copy, cut, delete, etc.).
• ZFS pools now feature extensive health monitoring, including support for
special vdevs (cache, log, etc.).
• Major performance improvements to ZFS dataset viewing and editing.
• Ability to flash images to ZFS zvols directly from the UI.
• Samba integration: Users can now create Samba shares. A comprehensive audit
log has been added to track file share activity.
Authentication
• Ability to create and manage users directly in the UI, including Samba
users.
• Groups can now also be created and managed from the UI.
Virtual Machines
• Full VM editing is now supported (storage, network, PCI devices, etc.).
• TPM support (via swtpm) is available in both UI and API, this feature is
currently experimental.
• Support for reusing existing raw disks.
• Added Wake-on-LAN functionality for VMs.
Jails
• Full support for thick jails (creation, editing, viewing).
• Resource limiting for CPU and RAM has been implemented.
• Networking for Jails supports both inherited configurations and
switch-based (manual/standard) setups.
Roadmap Update
Due to community demand, Q3 focused on clustering instead of firewalling and
network services. The following items have been pushed to Q4:
• Firewall rules configuration.
• DHCP support.
• WireGuard VPN integration.
The current roadmap is to complete clustering with external storage backup
support (e.g., S3) before returning to networking services.
Contributions, testing, and feedback are very welcome. If you are interested in
contributing, consider helping with:
• UI testing and accessibility feedback.
• Bug reports and feature requests via GitHub.
Sponsor: FreeBSD Foundation and Alchemilla (development and infrastructure
support)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
FreeBSD Git Weekly
Links:
FreeBSD Git Weekly URL: https://freebsd-git-weekly.tarsnap.net/
Contact: Graham Percival <gperciva@tarsnap.com>
These are weekly lists of commits to the FreeBSD source tree, split into
categories such as "documentation", "hardware support", "testing", and
"kernel".
Our goal is to make it easier for developers and users to keep track of changes
in FreeBSD that are relevant to them, without needing to subscribe to the
dev-commits-src-main mailing list and look at every single commit which lands
in their mailbox.
In the future, these reports might include summaries or additional information,
but for now our focus is figuring out what type of classification will be most
useful to the FreeBSD community.
These weekly reports began on 2025-09-01.
Sponsor: Tarsnap Backup Inc.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
July 2025 FreeBSD Hackathon in Berlin, Germany
Links:
Event page URL: https://wiki.freebsd.org/Hackathon/202507
Date: July Saturday 12th and Sunday 13th 2025
Location: Chaos Computer Club Berlin
We had been invited to hold our two day Hackathon in the halls of the Chaos
Computer Club Berlin. The full report can be found here.
The approximately 30 participants hacked on the following projects:
• Local Chatbot RAG with FreeBSD Knowledge
• Cross compiling FreeBSD on macOS
• Importing OpenSSL 3.5
• The netlinkification of PF
• Injecting host executable into jails
• Updating OpenSearch ports
• Ambushing Mark Phillips with a Microphone
• Patching rsync to handle extattr
• Checking LICENSE files against SPDX templates
• TCP/UDP checksum offloading for bhyve
• Native FreeBSD containers with Podman
• and more.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Userland
Changes affecting the base system and programs in it.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
ACPI Lua Bindings
Links:
GitHub URL: https://www.github.com/kpowkitty/freebsd-src
PR: libsa: Add isprint() URL: https://www.github.com/freebsd/freebsd-src/pull/
1740
PR: loader: Move ACPI RSDP detection URL:
https://www.github.com/freebsd/freebsd-src/pull/1843
PR: efi: Create libacpi URL: https://www.github.com/freebsd/freebsd-src/pull/1818
PR: liblua: ACPICA Lua bindings URL: https://www.github.com/freebsd/freebsd-src/pull/1819
Contact: Kayla Powell (AKA Kat) <kpowkitty@FreeBSD.org>
Mentor: Warner Losh <imp@FreeBSD.org>
Introduction
For Google Summer of Code 2025, I have been working on a project under Warner
Losh for ACPI Lua Bindings. ACPI (Advanced Power and Configuration Interface)
is an interface for managing power in the OS, rather than in the BIOS. The goal
is to expose ACPI to Lua in the loader for amd64 platforms, with future arm64
support.
Outcomes
• Lua is a much simpler, higher level scripting language that enables faster
development.
• It reduces ACPI-related guesswork in the bootloader.
• It allows users to query and manipulate ACPI data before the kernel is
entered, giving them control over loader-time configuration.
Remarks
If there are any specialized use cases for ACPI in the loader that my interface
does not aid in, please reach out to me, and I will see what I can do. For now,
this is the interface that I will be committing to the tree for GSoC, so while
any extra work will have to come afterwards, I am interested in it (and
encourage it).
Current status
• Completed:
□ ACPICA initialized in loader for amd64
☆ OsdMemory.c
☆ osunixxf.c
☆ AcpiInitializeSubsystem
☆ AcpiInitializeTables
☆ AcpiEnableSubsystem (in reduced hardware mode, with events enabled)
☆ AcpiLoadTables
☆ AcpiWalkNamespace
☆ AcpiEvaluateObject
☆ AcpiAttachData
☆ AcpiGetData
☆ AcpiDetachData
□ Lua bindings
☆ lacpi_walk.c
○ Users can walk and read nodes on the namespace
☆ lacpi_object.c
○ Users can evaluate objects
☆ lacpi_data.c
○ Users can attach, get, and detach data from nodes
☆ Man Page
• Future plans:
□ lacpi_walk.c (V2)
☆ Namespace printout format
□ lacpi_walk.c (V3)
☆ Strategies for walking the namespace
□ arm64 compat
Design constraints
The loader is meant to be lightweight and prepare the kernel. In order to
adhere to that, its initialization of ACPI has been reduced by 130 functions.
These functions were picked such that they were not necessary for the above
interface, or lacked possibility in the loader. They are:
• AcpiInitializeObjects
• AcpiInstallNotifyHandler
• AcpiRemoveNotifyHandler
Some functions needed to be stubbed in respect to the loader's limited library
(specifically in osunixxf.c). Some functions needed to handle physical
addresses, rather than virtual memory mappings (specifically in OsdMemory.c).
Testing
• Confirmation tests were performed, demonstrating that the ACPI namespace is
initialized correctly by dumping it in the loader (in C and in Lua) and in
the kernel (in C) and comparing the results.
• Regression tests were performed, ensuring FreeBSD builds across all
architectures with this change.
• Unit tests were performed on the Lua bindings, verifying their
functionality.
Sponsor: Google Summer of Code 2025
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Geomman Release
Links:
geomman gitlab repo URL: https://gitlab.com/brauliorivas/geomman
geomman port URL: https://www.freshports.org/sysutils/geomman
Contact: Braulio Rivas <brauliorivas@FreeBSD.org>
Geomman is a partitioning tool (TUI) based on sade(8) that brings more
functionality such as copying, pasting partitions, creating ext filesystems or
encrypting partitions using geli(8).
Geomman is relevant for both newcomers and experienced users because it is a
complete and unified management of partitions and disks.
Features added to geomman since last report are:
• Grow UFS, NTFS, ext2, ext3 and ext4 filesystems.
• Shrink NTFS, ext2, ext3 and ext4 filesystems.
• New partition dialog, where users can visually select a free space to place
the partition to be pasted or moved, added to bsddialog.
• Create exFAT, NTFS, ext2, ext3 and ext4 filesystems.
• Check all the mentioned filesystems.
Then, two GEOM-related features were added too:
• Label glabel(8) new partitions.
• Encrypt geli(8) new partitions by adding an optional "keyfile", plus a
"passphrase" (or passfile).
Finally, with the help of Robert Clausecker, we published the geomman port to
let people try it out.
Future work includes:
• Add geomman to FreeBSD natively (userland)
• Add ZFS management
Sponsor: Google Summer of Code 2025
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Sockstat UI Improvements
Links:
Sockstat UI Improvements wiki URL:
https://wiki.freebsd.org/SummerOfCode2025Projects/SockstatUIImprovements
Automatic column sizing PR URL: https://github.com/freebsd/freebsd-src/pull/1720
Reintroduced -w flag PR URL: https://github.com/freebsd/freebsd-src/pull/1746
Microoptimize cap-getnameinfo PR URL: https://github.com/freebsd/freebsd-src/pull/1753
Libxo support PR URL: https://github.com/freebsd/freebsd-src/pull/1770
Revert incorrect use of path-state for SCTP connections PR URL:
https://github.com/freebsd/freebsd-src/pull/1799
Complete libxo integration PR URL: https://github.com/freebsd/freebsd-src/pull/1806
Fix port parsing after libxo integration PR URL:
https://github.com/freebsd/freebsd-src/pull/1807
Contact: Damin Rido <rido@FreeBSD.org>
Sockstat is a command-line tool in FreeBSD that displays detailed information
about open network sockets. However, its traditional fixed-width formatting
made the output hard to read, especially when handling long addresses. This
project improves sockstat by introducing dynamically sized columns and
structured output support via libxo. With these enhancements, users can more
easily read output on the terminal or export the data in formats such as JSON,
XML, or HTML for scripting and integration with external tools.
The sockstat utility underwent improvements in two phases. First, the
fixed-width layout was replaced with dynamic column sizing using a two-pass
algorithm to ensure proper alignment and readability, including cases with long
socket addresses. The -w option was redefined to enable wide, auto-sized output
while maintaining compatibility with default terminal displays. In the second
phase, libxo support was integrated by replacing printf() calls with xo_emit(),
applying appropriate field tagging, and validating the output using libxo's
tools. The manual pages were updated to document the libxo integration. These
changes provide machine-readable structured output while preserving traditional
human-readable formatting.
Following the sockstat conversion, the parse_ports function was identified as
broken. Due to its complexity, the function warranted the addition of unit
tests to ensure correct behavior. The issue was addressed by fixing the
function and introducing a set of unit tests. The codebase was refactored by
renaming sockstat.c to main.c .
This project was part of Google Summer of Code 2025. It has modernized sockstat
and made it both more user-friendly and better suited for integration into
automated workflows.
Sponsor: Google Summer of Code 2025
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Process Credentials' Groups-Related Changes in FreeBSD 15
Links:
T2 2025 Status Report URL: https://www.freebsd.org/status/report-2025-04-2025-06/#_ucred_group_changes_in_freebsd_15_0
initgroups(3): Backwards-compatible implementation and manual page update URL:
https://cgit.freebsd.org/src/commit/?id=9dc1ac869196
Main commit changing getgroups(2)'s manual page URL:
https://cgit.freebsd.org/src/commit/?id=4be38acc826f
Main commit changing setgroups(2)'s manual page URL:
https://cgit.freebsd.org/src/commit/?id=6d22cd6b5f8b
Contact: Olivier Certner <olce@FreeBSD.org>
Contact: Kyle Evans <kevans@FreeBSD.org>
Starting with FreeBSD 15:
1. The behavior of the setgroups(2) and getgroups(2) system calls function has
slightly changed.
Out of caution, even if almost all existing applications will continue to
work undisturbed, we advise auditing those that you are maintaining or
using as explained below.
2. How processes' group membership is derived from the password and group
databases on login has slightly changed: The login user's initial numerical
group ID from the password database is now automatically added to the
supplementary groups set, even if that user is not explicitly listed as a
member of the corresponding group in the group database.
3. The kernel stores the effective group ID in a new specific field of struct
ucred (cr_gid) instead of in the same array as supplementary groups
(cr_ngroups[]).
The setgroups(2) and getgroups(2) system calls will operate only on the calling
process' supplementary groups, not featuring the effective group ID as the
first element of their array argument. The initgroups(3) function's
implementation is unchanged and still relies on setgroups(2), with the
consequence that it does not set the process' effective group ID anymore,
instead including its basegid argument in the supplementary groups set.
One of the reasons for these changes is to have FreeBSD behave exactly like GNU
/Linux systems, NetBSD, OpenBSD and illumos-based operating systems.
Consequently, almost all portable applications should already be compliant with
FreeBSD's new behavior and will continue to work correctly or even get fixed in
the process (see the previous status report linked above for an example with
OpenSSH). However, porters, system administrators and users are advised to
audit their applications that are using setgroups(2), getgroups(2) and
initgroups(3), watching out for the following points:
• Applications should already be using setgid(2) or setegid(2) in addition to
setgroups(2) or initgroups(3) to set the effective group ID.
If this is not the case, these calls must be added, as otherwise affected
applications will stop setting the effective group ID starting from FreeBSD
15.
• Applications using getgroups(2) should not be treating the first element of
the returned array specially, but as any other supplementary group.
If nonetheless they do, they have to be modified to obtain the effective
group ID via getegid(2) instead and to treat all groups returned by
getgroups(2) as supplementary groups only.
Manual pages of all changed functions have been modified in stable/14 and
stable/15 to describe and contrast the old and new behaviors, and have grown
new SECURITY CONSIDERATIONS sections stating the reasons for the changes and
the points to watch out for.
Backwards-compatible implementations of changed functions are provided so that
applications compiled on FreeBSD 14 or earlier continue to see the old
behaviors and work as before. They are available if and only if the kernel was
compiled with COMPAT_FREEBSD14, which is the case of the default GENERIC
kernel.
We have normally fixed all unwanted impacts of storing the effective group ID
separately from the supplementary groups in the kernel, such as:
• Some security policies or access checks would either ignore the effective
group ID or the first supplementary group (with lowest numerical ID),
affecting process visibility restrictions based on group IDs, the "can
debug" and "can export KTLS keys" checks, the mac_do(4) and mac_bsdextended
(4) security policies, and access control to some hardware facilities
(tracing: hwt(4); performance monitoring: hwpmc(4)) and to NFS-served
shares.
• Reporting of process' credentials would omit the effective group ID,
affecting all variants of procstat -s (on live processes, core files, or
system core dump), ddb(4).
Sponsor: The FreeBSD Foundation
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
The Gallant Console Font got Supercharged
Links:
Gallant Project URL: https://github.com/NanoBillion/gallant
Contact: Jens Schweikhardt <schweikh@FreeBSD.org>
The vt(4) console font "gallant" was extended in -CURRENT and 14-STABLE. This
increased the Unicode glyph count from 502 to more than 4500. Old-timers know
and love this font from watching Sun SPARCstations boot.
Major additions:
• Greek
• Cyrillic
• International Phonetic Association Extensions
• Extended Latin characters
• Zapf Dingbats
• Tons of arrows
• Tons of mathematical symbols
• Letterlike symbols and enclosed alphanumerics
• Pixel-perfect box drawing
• Currency symbols
• More punctuation
• Just enough Katakana to say コンニチハ
• Powerline glyphs in the Private Use Area at U+e0a0
Your help is needed to add more languages. You can contribute via the Gallant
Project.
But wait, there is more! You do not bother with console fonts and use X11
exclusively? Get that gallant feeling with the new port x11-fonts/gallant and
run
xterm -fa '' -fn '*-gallant-*'
To inspect the available glyphs under X11, run
xfd -fn '*-gallant-*'
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Kernel
Updates to kernel subsystems/features, driver support, filesystems, and more.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Audio Stack Improvements
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
Important work since last report:
• virtual_oss to base port in review: D52308, D52365, D52366, D52426, and
more.
• snd_hda(4) sound redirection patch (D50070) almost done.
• More sound(4) cleanups, fixes and improvements.
• More out-of-the-box laptop support.
• Wrote BSDCan 2025 trip report for the FreeBSD Journal.
• Working on FreeBSD Journal audio article.
You can also follow the development process in freebsd-multimedia@, where I
post regular reports.
Sponsor: The FreeBSD Foundation
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
DRM drivers
Links:
Update to Linux 6.10 DRM drivers URL: https://github.com/freebsd/drm-kmod/pull/371
Contact: Jean-Sébastien Pédron <dumbbell@FreeBSD.org>
DRM drivers are kernel drivers for integrated and discrete GPUs. They are
maintained in the Linux kernel and we port them to FreeBSD. As of this report,
we take the AMD and Intel DRM drivers only (NVIDIA FreeBSD drivers are
proprietary and provided by NVIDIA themselves).
We port them one Linux version at a time. This allows us to ship updates more
often and it eases porting and debugging because we have a smaller delta
compared to a bigger jump skipping several versions.
This quarter, the work was slower with the holidays. DRM drivers from Linux
6.10 were ported. However, there are still issues that need to be worked on:
• There is a regression in the integration of the amdgpu driver with vt(4),
causing the console to go blank once the driver is loaded. A graphical
session still works though.
• There are significant changes to the radix-tree support in linuxkpi that
needs more testing.
• The siphash code committed to linuxkpi is not working yet.
The pull request on GitHub and the associated freebsd-src branch may not have
the latest versions, until the compilation and load failures are fixed.
These updates target the FreeBSD 16-CURRENT development branch for now, but
linuxkpi changes should be backported to FreeBSD 15-STABLE.
The following pull request did not receive enough reviews and tests for now.
That is why they are still in flight.
• DMA_BUF_IOCTL_EXPORT_SYNC_FILE and DMA_BUF_IOCTL_IMPORT_SYNC_FILE ioctls
• DRM_IOCTL_SYNCOBJ_EVENTFD ioctl
They are apparently required to allow the use of wlroots-based Wayland
compositors with the Vulkan API (see https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=286311).
wlroots will need a patch as well because it only expects these features on
Linux for now.
Both pull requests rely on patches to linuxkpi. The linuxkpi patches are linked
in the pull requests.
This work is kindly sponsored by the FreeBSD Foundation as part of the Laptop
and Desktop Project.
Sponsor: The FreeBSD Foundation
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
DRM Drivers Slowdowns and Freezes Fixes
Links:
Main PR URL: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277476
drm-kmod GitHub issue URL: https://github.com/freebsd/drm-kmod/issues/302
Contact: Olivier Certner <olce.freebsd.statusreports@certner.fr>
Owners of AMD GPUs using the amdgpu DRM driver from the drm-kmod ports,
especially starting with v5.15 (drm-515-kmod), have been experiencing gradual
slowdowns and freezes since at least May 2024. Code analysis suggests that
recent Intel-based GPUs (gen 13+) may also be affected. We are pleased to
announce that, to the best of our knowledge, all these problems have been
fixed.
We encourage people to test the latest FreeBSD code on branches main, stable/15
or stable/14. The fixes will be included in the upcoming 15.0 and 14.4
releases. Errata notices and patches may be issued for 14.3 in order for people
not to have to wait until 14.4 (whose release should tentatively happen next
March). An additional fix will find its way in the drm-kmod ports (see below).
Investigations revealed that the crux of all these problems has been bad
handling of too frequent, and generally not really necessary, physically
contiguous memory allocation requests in fast paths. Basically, the DRM's TTM
component tries to allocate pools of graphics memory pages that are as much as
possible physically contiguous in order to reduce the number of corresponding
TLB entries. It does it in a loop that first tries to allocate pages of higher
order with the __GFP_NORETRY flag, gradually falling back to smallest ones (see
ttm_pool_alloc()).
The first problem is that our LinuxKPI did not handle Linux's __GFP_NORETRY
flag and would try hard to fulfill the first requests, i.e., those with highest
order pages, using expensive mechanisms to obtain or produce contiguous memory
if not readily available. A first fix by Mathieu (sigsys at gmail with regular
company suffix) removed memory compaction from this process (foregoing calls to
vm_page_reclaim_contig()). This fix was then completed by stopping the VM
system from trying to break memory reservations, which are pieces of a
speculative mechanism that tries to automatically provoke the use of
superpages.
Another problem came from evolutions of our LinuxKPI. In order to better comply
with what Linux does, kmalloc() was changed to always return physically
contiguous memory. Unfortunately, kvzalloc(), which relied on kmalloc() in our
implementation (which was conceptually wrong, but initially harmless in
practice), was not switched to rely on kvmalloc() in the process, effectively
turning large memory allocations of zeroed pages into costly physically
contiguous ones.
Some rough profiling of slowdowns was done using dtrace. It revealed that a
fair amount of execution time of the failing allocations came from attempting
multiple allocations in the same NUMA domain. An analysis of the VM domainset
iterators code revealed multiple flaws, in particular leading to re-examining
the same domain multiple times (up to 4 times for the common case of machines
with a single domain) without any additional guarantees of success for new
attempts. Some other VM domainset problems have been fixed in the process, such
as ensuring that allocation requests prefer domains not on a low memory
condition in all situations. As for succeeding allocations, they would trigger
useless changes to page attributes, leading to expensive TLB shootdowns.
Finally, concerning specifically the amdgpu driver and affecting only Carrizo,
Polaris and Vega M based AMD GPUs, a temporary allocation that was
unnecessarily physically contiguous was replaced with a regular one, making the
remaining, relatively short but noticeable freezes disappear. By contrast with
those evoked above, this change is to the drm-kmod ports' code. It has been
included in the latest version bumps in the ports tree. Check that your package
versions, for drm-510-kmod, drm-515-kmod, drm-61-kmod and drm-66-kmod, are
respectively equal or greater than 5.10.163.*_13, 5.15.160.*_8, 6.1.128.*_7 and
6.6.25.*_6, where * stands for the __FreeBSD_version value on the build system.
This work was sponsored by the FreeBSD Foundation as part of the Laptop
Project.
Sponsor: The FreeBSD Foundation
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
LinuxKPI 802.11 and Native Wireless Update
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.
Work is ongoing for Mediatek mt76-based PCIe card support.
LinuxKPI 802.11 (linuxkpi_wlan(4)) updates were committed for scanning and
beacon handling improvements and more robustness.
LinuxKPI updates were done in order to import newer versions of iwlwifi(4),
rtw88(4), and rtw89(4) drivers. Work on suspend and resume for LinuxKPI-based
wireless drivers has a possible solution which will need community testing and
feedback. Both updates were blocked by out-of-tree drm LinuxKPI PCI conflicts
and problems were just resolved before EuroBSDCon 2025 thus the work will
likely appear beginning of 25Q4.
I gave a talk on wireless at EuroBSDCon 2025 and had a good chat with wireless
people from NetBSD and OpenBSD.
There is increasing interest again in getting brcmfmac support sorted, as well
as more requests for ath11k.
Sponsor: The FreeBSD Foundation
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
mac_do(4) and mdo(1) Improvements
Links:
Wiki page URL: https://wiki.freebsd.org/SummerOfCode2025Projects/MacDoAndMDoImprovements
Commit to mdo(1) enabling fine-grained credentials transition requests URL:
https://cgit.freebsd.org/src/commit/?id=3ca1e69028ac
Contact: Kushagra Srivastava <thesynthax@FreeBSD.org>
Contact: Olivier Certner <olce@FreeBSD.org>
The mac_do(4)/mdo(1) project aims at allowing controlled process credentials
transitions without using setuid executables but instead leveraging our MAC
framework. For more information, please consult the associated manual pages as
well as previous status reports from T3 2024 and T4 2024.
As part of Google Summer of Code 2025, Kushagra worked on extending mac_do(4)
(kernel) and mdo(1) (userland).
Worked-on mac_do(4) features:
• Per-jail configuration of authorized executables: Allow administrators to
specify a per-jail list of executables that are permitted to request
credential transitions, instead of being limited to the hardcoded /usr/bin/
mdo.
• Support for traditional credential-changing system calls: Allow mac_do(4)
to assess calls to setuid(2), setgid(2), setgroups(2), and related
functions as full credentials transitions on their own.
Worked-on new mdo(1) features:
• Allow finely specifying target groups (-g, -G, -s options), inheriting from
current credentials or those of some user in the password and group
databases, and explicitly overriding any user and group IDs and
supplementary group.
• Provide a --print-rule option to switch to a mode that displays an example
of the target part of a rule that would match the requested credentials.
Of these, the mdo(1)'s new fine-grained credentials transition requests change
has been committed and will appear in 15.0 and 14.4. The others most probably
will land in stable/14 before 14.4, but seem unlikely to appear in 15.0 as they
need more review and some amendments.
Together, these improvements will make mac_do(4) and mdo(1) more flexible and
practical, enabling safer credentials transitions without relying on setuid
executables and with strong jail integration.
Sponsor: Google LLC (Google Summer of Code 2025)
Sponsor: The FreeBSD Foundation
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Suspend/Resume Improvement
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 Repository URL: https://github.com/obiwac/freebsd-s0ix/tree/everything
Tip of the s2idle/S0ix + AMD SMU stack URL: https://reviews.freebsd.org/D48721
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.
Entry to S0i3 is now working reliably on the Framework 13 AMD Ryzen 7040 series
laptops on FreeBSD 15. This required changes to LinuxKPI for DRM to know
whether the system intends to enter S3 or S0ix: D51591.
These changes in turn required the creation of generic sleep types, separate
from ACPI. Not all of these changes have yet been committed, but new hw.power.*
sysctls will be created to choose the sleep type for various sleep state
transition requests.
The amdsmu driver, some ACPI changes and fixes, and GPIO interrupt servicing in
amdgpio have been committed.
A pre-built sleep testing image is now available to easily testing S0i3 entry
on machines. Detailed instructions are on the webpage.
With respect to the links, the blog post entry is still outdated.
Sponsor: The FreeBSD Foundation
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
USB Kernel Debugging Improvements
Contact: Tom Jones <thj@FreeBSD.org>
XHCI USB controllers offer a mode which allows them to be used as a system
debugging interface. XHCI debug uses a special USB 3 cable with VBUS, D+ and D-
disconnected. The feature can be used to live debug the FreeBSD kernel,
enabling investigation of issues which cause the system video console to lock
up and there is not an alternative such as a serial console. This can happen
when debugging issues with graphics drivers.
Hiroki Sato developed support for the XHCI debug interface and made it
available as some in progress git branches. This implementation enables FreeBSD
to operate as both a Debug Host and a Debug Target, with support for debugging
from the loader through to the kernel.
In this quarter the Debug Host side of the XHCI debug has been committed to
FreeBSD main and will be available in FreeBSD 15. The Debug Host driver enables
a FreeBSD machine to debug Linux and Windows systems acting as Debug Targets.
The Debug Host driver has been split from the patch series to enable debugging
of FreeBSD 16 and onwards from FreeBSD 15.
The Debug Target side of XHCI debug has progressed in this quarter, with an
improved interface between the loader and the kernel and a lock up sending data
from a Target resolved. The remaining work for the host implementation is to
enable XHCI debug as a console very early in boot and to convert some methods
to use bus space allocations.
In the coming quarter I plan to update the developers handbook section on
kernel debugging.
Sponsor: The FreeBSD Foundation
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Architectures
Updating platform-specific features and bringing in support for new hardware
platforms.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
FreeBSD Driver Development for BananaPi-R64
Links:
Wiki URL: https://wiki.freebsd.org/arm/Bananapi
Contact: Martin Filla <freebsd@sysctl.cz>
Introduction
The Banana Pi R64 is a MediaTek MT7622-based development board (ARM Cortex-A53,
dual-core ~1.35 GHz) featuring 4× Gigabit LAN, 1× Gigabit WAN, Wi-Fi (4×4n),
Bluetooth 5.0, and multiple peripheral interfaces (UART, SPI, I²C, GPIO, SATA,
mini-PCIe, eMMC, etc.).
Current State of FreeBSD Support
• Implemented so far:
□ UART driver
□ Clock management (clocks)
□ Pinctrl/gpio driver – in active development gpio part
□ Storage controllers (eMMC/SD/MMC) driver
□ Ethernet Switch mt7531 driver
□ Ethernet mt7622 driver
Other essential components—Ethernet, USB, SATA, Wi-Fi, etc.—are not yet
implemented.
Technical Context and Significance
Support for Banana Pi R64 in FreeBSD is in the early stages—UART and clocks
drivers exist but ppl clock is under development, gpio is under
development — while most critical subsystems remain unimplemented.
Development roadmap
• Implement missing drivers
□ USB (XHCI/OTG)
□ SATA / AHCI
□ Wi-Fi (likely MediaTek MT7615)
□ GPIO subsystems
Conclusion
Support for Banana Pi R64 in FreeBSD is in the early stages—UART and clocks
drivers exist but ppl clock is under development, gpio is under
development—while most critical subsystems remain unimplemented. Publishing
working code and artifacts, plus active collaboration with the FreeBSD
community, will be essential to bring this board toward usable status under
FreeBSD.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Cloud
Updating cloud-specific features and bringing in support for new cloud
platforms.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Improvements for nuageinit
Contact: Baptiste Daroussin <bapt@FreeBSD.org>
Contact: Jesús Daniel Colmenares Oviedo <dtxdf@FreeBSD.org>
Inspired by cloud-init, nuageinit is a script written entirely in Lua to add
cloud-init compatibility to FreeBSD. Thanks to the firstboot feature of the rc
(8) framework, it runs early and only once.
Fixes and improvements have been made in recent months:
• Missing documentation for already implemented parameters have been added.
• More test cases have been added.
• The device configuration ID is used as an interface when no match rule is
specified.
• Implementation of the network.ethernets.{id}.match.name parameter.
• Implementation of the network.ethernets.{id}.wakeonlan parameter.
• Implementation of the network.ethernets.{id}.set-name parameter.
• Implementation of the network.ethernets.{id}.match.driver parameter.
• Implementation of the network.ethernets.{id}.mtu parameter.
• Implementation of the nameservers parameter.
• Support for security/doas.
• Allow the use of network parameters from network-config file.
Committed in the following branches: stable/14, stable/15, and main.
If you plan to use nuageinit, remember that each image is generated
periodically and distributed on the following sites:
• https://download.freebsd.org/releases/VM-IMAGES
• https://download.freebsd.org/snapshots/VM-IMAGES
Commits: ba5df7a, 95b0be1, a7f1996, 9f3330f, 9f3330f, 95230b2, 9a829e8
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Documentation
Noteworthy changes in the documentation tree, manual pages, or new external
books/documents.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Documentation Engineering Team
Links:
FreeBSD Documentation Project URL: https://www.freebsd.org/docproj/
FreeBSD 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: FreeBSD Doceng Team <doceng@FreeBSD.org>
The doceng@ team is a body to handle some of the meta-project issues associated
with the FreeBSD Documentation Project; for more information, see FreeBSD
Doceng Team Charter.
Team changes:
• doceng@ welcomes ziaee@ as a new member (lurker).
• ebrandi@ promoted to full doceng@ membership.
During the last quarter:
• vladlen@ obtained a translator commit bit, with maxim@ as mentor.
• reactivation of documentation commit bit for andy@ with both mentors
carlavilla@ and maxim@
Document changes
• Handbook
□ The X11 chapter has been updated and restructured
Many style and content fixes in various documents.
• Documentation repository:
□ Added manual pages for macOS 26.0
□ Updated manual pages for macOS to 14.8 and 15.7
□ Added manual pages for Debian 13.0.0
FreeBSD Translations on Weblate
Translate FreeBSD on Weblate URL: https://wiki.freebsd.org/Doc/Translation/Weblate
FreeBSD Weblate Instance URL: https://translate-dev.freebsd.org/
Q3 2025 Status
Languages
• Chinese (Simplified) (zh_CN) (progress: 7%)
• Chinese (Traditional) (zh_TW) (progress: 3%)
• Dutch (nl_NL) (progress: 1%)
• French (fr_FR) (progress: 1%)
• German (de_DE) (progress: 1%)
• Greek (progress: 1%)
• Indonesian (progress: 1%)
• Italian (it_IT) (progress: 4%)
• Korean (progress: 29%)
• Norwegian Bokmål (progress: 1%)
• Persian (progress: 3%)
• Polish (progress: 1%)
• Portuguese (progress: 0%)
• Portuguese (Brazil) (progress: 23%)
• Russian (done: 100%)
• Spanish (progress: 35%)
• Turkish (tr_TR) (progress: 1%)
We want to thank everyone that contributed, translating or reviewing documents.
And please, help promote this effort on your local user group, we always need
more volunteers.
Packages maintained by DocEng
During this quarter the following work was done in packages maintained by
doceng@:
• www/gohugo: update to 0.151.0
Open issues
There is 1 Open PRs in bugzilla assigned to doceng@:
• 267274 Please remove the zh-CN Handbook of the current FreeBSD website
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
The FreeBSD Russian Documentation Project
Links:
FAQ URL: https://docs.freebsd.org/ru/books/faq/
Web URL: https://www.freebsd.org/ru/
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.
In September 2025, two committers were granted commit bits to write
Russian-translated documentation into the FreeBSD documentation tree:
• Andrey Zakhvatov, co-mentors Sergio Carlavilla and Maxim Konovalov
• Vladlen Popolitov, mentor Maxim Konovalov
During the last quarter:
• 100% of the text has been translated in Weblate.
• 31 out of 47 documents have been updated to the latest version from
docs.FreeBSD.org/ru, with the remaining documents currently under review
and awaiting commit.
This report acknowledges with appreciation the contributions of the following
colleagues who performed reviews of our commits during the quarter (in
Phabricator or by email):
• Gleb Popov
• Benedict Reuschling
• Eugene Grosbein
• Maxim Konovalov
• Michael Zhilin
Plan for next quarter:
• Finalize the review and commit process for documentation (books and
articles)
• Restore the Russian pages on www.FreeBSD.org
• Review the feasibility and the mechanics of the man pages translation
Check the official translation guide if you would like to help.
We would appreciate your assistance with translating the following materials:
• Web pages
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Ports
Changes affecting the Ports Collection, whether sweeping changes that touch
most of the tree, or individual ports themselves.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
A bhyve management GUI written in Freepascal/Lazarus
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:
• Add swtpm support to FreeBSD >=1403000.
• Add x86.verbosemsr setting on FreeBSD >=1500023.
• Add IPv6 support. It enhances a better IPv6 support using dns/dnsmasq. A
host-record will be added to dnsmasq when Use_IPv6 is enabled.
• Add a bridge IPv6 calculator at Bhyve Manager Settings. It helps us to
calculate what IPv6 must be assigned to bridge interface. Take a look at
README for more information about that.
• Add support to create virtual machines from Cloud or VM images. A new page
will appear when "Create a virtual disk from image" option is selected. It
includes an image downloader (only support img.xz, raw.xz, qcow2.xz, qcow2,
img, and raw files).
• Add Cloud init/Nuageinit configuration files support.
• Add user-data, network-config, and meta-data templates used from image
minimal configuration.
• Add user-data, network-config, and meta-data samples files.
• Add support to define static ipv4 address when files configuration is
selected from "Create Virtual Machine/Image" form.
• Add new option to select images path directory from "Settings". This
directory is used to storage extracted images files. By default, it is
located at ~/.bhyvemgr.
• Add new option to define qemu-img path file.
• Add i18n support with initial English, Simplified Chinese (thanks to ykla)
and Spanish translations.
• Enhanced logging support.
• Enhanced clipboard support.
Bhyvemgr supports aarch64 from 15-PRERELEASE to 16-CURRENT and amd64 from
FreeBSD 13.x to 16-CURRENT. Also, sysutils/bhyvemgr can be compiled or
installed from ports or pkg binaries with gtk2, qt5 or qt6 interface support.
People interested in helping or supporting the project are welcome.
Sponsor: https://paypal.me/alonsocbsd
Current version: 1.12.0
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Container orchestration: Overlord, Director, AppJail and cloud-init
Links:
AppJail on GitHub URL: https://github.com/DtxdF/AppJail
Director on GitHub URL: https://github.com/DtxdF/Director
Overlord on GitHub URL: https://github.com/DtxdF/Overlord
Makejails URL: https://github.com/AppJail-makejails
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.
Director is a tool for running multi-jail environments on AppJail using a
simple YAML specification. A Director file is used to define how one or more
jails that make up your application are configured. Once you have a Director
file, you can create and start your application with a single command:
appjail-director up.
Overlord is a fast, distributed orchestrator for FreeBSD jails oriented to
GitOps. You define a file with the service intended to run on your cluster and
deployment takes seconds to minutes. This orchestration tool uses AppJail,
Director and can even create VMs with vm-bhyve, but as its philosophy is
"deploy using code" you can create a single file once and deploy many times.
Through a tree chaining system Overlord deploys jails on connected systems
sharing their resources almost infinitely. See the wiki for articles that use
Overlord.
Recently written articles about Overlord:
• Overlord: Deploy Jails as Fast as You Code
• Deploying virtual machines using cloud-init
• Deploying virtual machines with ephemeral jails
• Using GitOps with Overlord
• How to install Jellyfin and Jellyseerr using Overlord
Makejails are simple text files that automate the steps to create a jail, a
widely used feature of AppJail. Currently, there are many Makejails created and
hosted in the Centralized Repository, but here are some of the recently written
ones:
• Odoo
• WriteFreely
• Adminer
• Shiori
• Healthchecks
• ntfy
Sponsor: https://www.patreon.com/appjail
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Improve libvirt support for bhyve hypervisor
Links:
CI for libvirt/bhyve on FreeBSD URL:
https://empt1e.blogspot.com/2025/09/ci-for-libvirtbhyve-on-freebsd.html
Contact: Roman Bogorodskiy <novel@FreeBSD.org>
Completed work
• Support for pf(4)-based NAT networking was merged and has been available
since libvirt 11.7.0 release.
• Domain usage statistics reporting is also available starting with libvirt
11.7.0 release.
• TCP console support has been available since libvirt 11.6.0 release.
• The libvirt testing project, libvirt-tck, can now successfully run domain,
network, and storage tests against the bhyve driver.
Plans for the next quarter
• Extend libvirt-tck testing with hooks tests.
• Add support for:
□ Boot order configuration.
□ TPM devices.
□ Snapshot/resume to the bhyve driver (targeted, but might roll over to
next quarter).
• Improve virt-manager support on FreeBSD.
Sponsor: The FreeBSD Foundation
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Improve OpenJDK on FreeBSD
Links:
Project description URL: https://freebsdfoundation.org/project/improving-openjdk-on-freebsd/
Project repository URL: https://github.com/freebsd/openjdk
Contact:
Harald Eilertsen <haraldei@freebsdfoundation.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:
• The OpenJDK 24 port was updated to OpenJDK 24.0.2, and once more to include
several fixes for the serviceability agent and performance improvements for
large Elastic- and OpenSearch workloads. The serviceability improvements
fixes symbol and thread lookups when attaching to another JVM, and fixes
loading core files in the Java debugger on FreeBSD.
• The OpenJDK 23 port was updated to include IPv6 dual protocol socket
support (like OpenJDK 24), as well as the performance improvements for
Elastic- and OpenSearch.
• OpenJDK 8, 17 and 21 were updated to the latest releases from upstream, and
a new port for installing just the Java Runtime Environment (JRE) of
OpenJDK 21 was added.
• Build issues causing the official pkg builds of some older java versions on
certain FreeBSD revisions to fail, was debugged and fixed by Ronald Klop.
Sponsor: The FreeBSD Foundation
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
KDE on FreeBSD
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.
We missed last quarterly status report. The changes from the second quarter are
included in this report.
Infrastructure
CMake was updated to 3.31.9, the latest release in 3.x series. Ninja was
updated to 1.13.1.
Qt6 was updated to 6.9.2. Both of the Python bindings for the Qt6 toolkit have
been updated to their latest releases:
• PyQt6: updated to 6.9.1
• PySide6: updated to 6.9.2
The graphics/qt6-wayland port was patched to fix crashes of Plasma on Wayland
when right-clicking the desktop.
Qt5 was updated to 5.15.17 KDE patch collection. Upstream standard support for
Qt5 is officially over. This might be the last update for Qt5 on FreeBSD.
The www/qt5-webengine port has been updated to 5.15.19 with security patches up
to Chromium 135.0.7049.95. The Qt5 WebEngine component, however, is and forever
will be based on Chromium 87.0.4280.144, which is over 4 years old. Security
updates for the underlying Chromium base have now ceased. Use at your own risk.
KDE Stack
KDE Frameworks, Plasma, and Gear release happen very regularly. KDE team lands
these updates shortly after their upstream release.
• KDE Frameworks reached version 6.18.0.
• KDE Plasma Desktop was updated to 6.4.5.
• KDE Gear was updated to 25.08.1.
Plasma 6.5 Beta (6.4.90) was ported but not committed to the main ports-tree.
The net-mgmt/kf6-networkmanager-qt port with stub implementation for Linux
NetworkManager was added to aid porting third-party software.
Related Ports
The KDE team maintains a wide range of ports and updates them all as needed.
According to Portscout less than 0.7% ports are outdated.
The KDE team would like to thank Dima Panov, Gleb Popov, Jason E. Hale, Kenneth
Raplee, Loïc Bartoletti, and Max Brazhnikov for keeping things up-to-date. The
KDE team is grateful to Harley (SponiX on IRC) for sharing his building box.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
GCC on FreeBSD
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>
The exp-run to update GCC default version from 13 to 14 is almost done at the
time this report is written: only one last PR stays open. Hopefully, the update
has been finally done when you are reading these lines. However I remind you
that the latest GCC major version is GCC 15, so we will still be behind one
version. Of course, another exp-run will be prepared to update GCC_DEFAULT to
GCC 15, but not immediately. I will wait some time to ensure that the
GCC_DEFAULT=14 update has indeed worked as expected and to deal with some other
issues related to the GCC ports.
Another important change concerns bootstrapping. The GCC ports were in an
inconsistent state: some ports required a bootstrap option to be chosen, while
others did not. Now all GCC ports allow building without any bootstrap option
selected, just as it was in the past.
The problem is that building GCC on FreeBSD with FreeBSD's default compiler
(clang) is not fully supported. Since I know that many users do prefer to build
GCC without bootstrapping it, instead of enforcing it as I initially planned, I
prefer to maintain the option but remove from a no-bootstrap build all features
that cannot be built successfully. It shall be the users' responsibility to
ensure that they do not need any feature incompatible with no-bootstrap builds.
At the moment, jit is the only feature that is excluded from a no-bootstrap
build. The default bootstrap option is STANDARD_BOOTSTRAP, so users of packages
from official FreeBSD packages repositories will have a full build with all the
supported features available.
See commits 5ee63cc45413954077b2b0c0546b8342585b41ba,
62f186cdf6e9689f30e854a0e23482c552c851a2 and this mail for more details.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Valgrind: preparing for 15.0-RELEASE
Links:
Valgrind Home Page URL: https://www.valgrind.org/
Valgrind News URL: https://www.valgrind.org/docs/manual/dist.news.html
arm64 port URL: https://github.com/paulfloyd/freebsdarm64_valgrind
Contact: Paul Floyd <pjfloyd@wanadoo.fr>
I have not submitted any reports for over a year. On the whole that is good
news as it means that there have not been any major issues. Back then I said
that aarch64 support was about to land and indeed it did in mid April 2024.
I added a nice little script for use with Valgrind called vgscript. This works
in a similar manner to pstack (or bstack on FreeBSD) in that you give it a PID
and it will generate a stack trace for that process. If you use bstack with a
Valgrind process you will see the Valgrind call stack which is probably of no
use to you. If you run vgstack with a Valgrind PID it will print the call stack
of the test exe running under Valgrind.
If you use Valgrind regularly could you take a look and answer the survey that
I posted on the forums (if you have not done so already). Here is the link.
Valgrind 3.26 is due out at the end of October 2025 and devel/valgrind will be
updated shortly after that.
devel/valgrind-devel will get one (or maybe more) updates as I fix issues with
FreeBSD 15.0.
The outstanding issues that I have on FreeBSD 15.0 are * aarch64: there is a
problem when using Valgrind with gdb/vgdb. Hitting ctrl-c to interrupt the
process running under Valgrind does not work and Valgrind crashes with an
assert. * aarch64: a known old issue that was infrequent regarding
initialisation of thread memory now seems to occur much more often. * amd64:
maybe similar to the first issue with gdb/vgdb and interrupting a process, but
this time I am seeing select return an 'impossible' value. * amd64: a test for
setcred is getting an extra "Conditional jump" error message.
Most of the above are not too serious unless you are a heavy user of gdb/vgdb.
Here is a list of bugfixes since my last report, Q1 2024.
• Several suppressions added for libc, libc and libstdc functions
• Improvements to setcontest argument checking
• Some more aio_* fixes
• Syscall _sysctlname was checking the wrong length of the name argument
• New syscall wrappers for kcmp, getrlimitusage, close_range, fchroot,
setcred, exterrctl, inotify_add_watch_at, inotify_rm_watch, jail_attach_jd
and jail_remove_jd
• Started adding better ioctl argument checking
• Fixes to Valgrinds self-checking modes
• Support aarch64 auxv AT_HWCAP, AT_CHERI_STATS, AT_HWCAP3 and AT_HWCAP4
• Valgrind file descriptor checking has been significantly enhanced and this
includes FreeBSD
• Some old code that I could never test for FreeBSD 10 has been removed
• Removed as much as possible FreeBSD version dependent code. This reduces
everyday maintenance at the cost of making version-independent regression
tests more difficult
• Turn off check for lock created during text handling that will deliberately
leak
• Syscall sigwait was not correctly dealing with its atypical return value
• Improved checking of utrace syscall arguments
• amd64: syscall arguments 7 and 8 were swapped (it turns out that argument 8
is never needed and has been removed)
• amd64: added sysarch subcommands AMD64_SET_TLSBASE and AMD_GET_TLSBASE
• Reduced warnings that get printed in quiet (-q) mode
• Improved checking done by sysctl kern.proc.pathname
• Handle mmap MAP_STACK and MAP_GUARD
• Syscalls open* now produce an error if you try to open the guest exe for
writing
• Syscalls sigwait and sigwaitingfo were too lax in accepting NULL arguments
• Many of the *at system calls (like faccessat) were not checking that the
directory fd is not one of the file descriptors reserved for Valgrind's use
• Function memalign now accepts a size of zero
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
A new Wi-Fi management utility: wutil
Links:
source code URL: https://github.com/MainKt/wutil
port URL: https://www.freshports.org/net/wutil
Contact: Muhammad Saheed <saheed@FreeBSD.org>
net/wutil is a Wi-Fi management utility that supports most wpa_supplicant(8)
station-mode operations (scanning, connecting or disconnecting from wireless
networks, and managing known networks, etc.), accessible with much nicer
interfaces. It also automatically manages and updates wpa_supplicant.conf(8).
SSIDs with Unicode characters are also handled nicely.
wutil(8) is the Command-Line Interface (CLI), whereas wutui(8) is the Terminal
User Interface (TUI). wutui was built without any dependency on TUI libraries,
by just spell-casting ANSI escape sequences in uncooked terminal raw mode and a
kqueue(2) based event loop. Both utilities communicate with wpa_supplicant via
its control socket interface. There is also a dependency on net/libifconfig for
interface related functions.
In the future, I plan to support AP-mode operations from hostapd(8), clean up
the TUI components and perhaps move away from wpa_supplicant to handle
authentication in-house.
wutil is now available in ports. Give it a whirl! Contributions, bug reports
and feature requests are very welcome on GitHub.
Mentors: Aymeric Wibo and Getz Mikalsen
Sponsor: Google Summer of Code 2025
