FreeBSD The Power to Serve

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.

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:

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(2).

  • 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(1).

  • 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:

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:

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:

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:

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:

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:

Bug fixes:

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:

Unskip tests that are wrongly skipped in CI:

Test case metadata fixes:

mark tests as "expected fail" (xfail), currently WIP:

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:

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:

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.

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:

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:

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):

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:

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:

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

Last modified on: November 30, 2025 by Lorenzo Salvadore