FreeBSD The Power to Serve

FreeBSD Status Report First Quarter 2024

Here is the first 2024 status report, with 21 entries.

The New Year brings us many new interesting projects, such as the new libsys that separates system calls from libc and libpthread or work on a graphical installer for FreeBSD, which will help making our OS more user-friendly. Of course, the usual projects keep going on, such as the work on cloud-init, OpenStack, or the GCC ports. As usual our main teams share their progress with us.

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

The FreeBSD Core Team is the governing body of FreeBSD.


FreeBSD 13.3 was released on March 5th, 2024.

The release announcement is at:

Along the release engineering team, the project dedicates the 13.3-RELEASE to Glen Barber, with thanks for his many years of contributions as Release Engineer.

Future of 32-bit platform support

Core announced Future of 32-bit platform support in FreeBSD for deprecating 32-bit platforms over the next couple of major releases.

Commit bits

FreeBSD Foundation

Contact: Deb Goodkin <>

The FreeBSD Foundation is a 501(c)(3) non-profit organization dedicated to supporting and promoting the FreeBSD Project and worldwide community, and helping to advance the state of FreeBSD. We do this in both technical and non-technical ways. We are 100% supported by donations from individuals and corporations and those investments help us fund the:

  • Software development projects to implement features and functionality in FreeBSD

  • Sponsor and organize conferences and developer summits to provide collaborative opportunities and promote FreeBSD

  • Purchase and support of hardware to improve and maintain FreeBSD infrastructure

  • Resources to improve security, quality assurance, and continuous integration efforts

  • Materials and staff needed to promote, educate, and advocate for FreeBSD

  • Collaboration between commercial vendors and FreeBSD developers

  • Representation of the FreeBSD Project in executing contracts, license agreements, and other legal arrangements that require a recognized legal entity


We kicked off the new year with ambitious goals to help move the FreeBSD Project forward by identifying features and functionality to support in the operating system and increasing our advocacy efforts to increase and expand the visibility of FreeBSD. Stay tuned for a blog post that will provide more information on our 2024 goals and plans.

We also published the 2024 Budget. In order to provide greater transparency about the budgeting process, we wrote a blog post that provides more details on how funding is allocated, new breakouts of some of the project expense categories, and more details on where the funding is going.

OS Improvements

During the first quarter of 2024, 180 src, 65 ports, and 18 doc tree commits identified The FreeBSD Foundation as a sponsor.

Three new projects began this quarter.

  • Work began to improve FreeBSD’s audio stack and provide audio developers with useful tools and frameworks to make sound development on FreeBSD easier. Read more in Christos Margiolis Audio Stack Improvements report entry.

  • Olivier Certner began his second contract with the Foundation, and this time around, the main goal is to make unionfs stable and useful on FreeBSD. Other work may include revamping VFS lookups, improving out-of-memory handling, implementing a notification system for en-masse detection of filesystem changes such as inotify, and improving console usability.

  • This quarter, a new project to add hierarchical rate limits to the OpenZFS file system began. Pawel Dawidek will add support for limits that will be configurable, similar to quotas, but would limit the number of read/write operations and read/write bandwidth.

Six projects continued this quarter.

  • You can read about the continued work to port OpenStack components to FreeBSD in Chih-Hsin Chang’s OpenStack on FreeBSD report entry.

  • Work continued to improve cloud-init support for FreeBSD. You can read about Mina Galić’s work in her FreeBSD as a Tier 1 cloud-init Platform report entry.

  • A new joint project began between Advanced Micro Devices (AMD) and The FreeBSD Foundation to develop a complete FreeBSD AMD IOMMU driver. This work will allow FreeBSD to fully support greater than 256 cores with features such as CPU mapping and will also include bhyve integration. For those interested in the technical details, follow Konstantin Belousov commits tagged with Sponsored by fields for Advanced Micro Devices (AMD) and The FreeBSD Foundation.

  • Refer to Pierre Pronchery’s Graphical Installer for FreeBSD report entry to read about the status of FreeBSD’s new graphical installer.

  • Work continues to port the Vector Packet Processor (VPP) to FreeBSD. VPP is an open-source, high-performance user space networking stack that provides fast packet processing suitable for software-defined networking and network function virtualization applications. Look for a pending article from the developer working on the project, Tom Jones, that details the experience of porting VPP to FreeBSD.

  • Björn Zeeb and Cheng Cui continue their wireless work. This quarter was mostly focused on bug fixes and stability improvements to LinuxKPI 802.11 and net80211. Much of this work made it into the 13.3 release.

Here is a sampling of other Foundation-sponsored development completed over the first quarter of 2024:

  • FreeBSD was accepted in Google Summer of Code 2024 after receiving 22 contributor proposals; on May 1, we will learn how many projects we will be awarded

  • OpenSSH: update to 9.6p1 then 9.7p1

  • Deprecate bsdlabel

  • Import the kernel parts of bhyve/arm64

  • Various RISC-V improvements

FreeBSD Infrastructure

A contract was completed to set up a new cluster site at NYI Chicago. You can read about the details of that project on the Foundation’s blog.

Continuous Integration and Workflow Improvement

As part of our continued support of the FreeBSD Project, the Foundation supports a full-time staff member dedicated to improving the Project’s continuous integration system and the test infrastructure. The full update can be found within the quarterly status report.

Partnerships and Research

A focus of Partnerships this Quarter has been to educate the industry about the innovations in the FreeBSD community and the impact that FreeBSD continues to have as a cornerstone to our digital society. This is an ongoing priority, and one we invite (encourage) everyone using and working on FreeBSD to join us in. Greg Wallace, the Foundation Partnerships lead, is grateful for the opportunities he has had to meet with open source and industry leaders at Microsoft, Google, AWS, OpenSSF, Alpha-Omega, CISA, Eclipse Foundation, Open Source Initiative, Apache Software Foundation, Rust Foundation, Red Hat, Linux Foundation and many others to ensure they have visibility into the key role FreeBSD plays in the global digital infrastructure. This is a role FreeBSD has earned through its technical excellence, security by design, high availability, simplicity of operations, commitment to open source collaboration, and cohesiveness.

One sees these characteristics of FreeBSD in the important ongoing funded development work such as porting VPP to FreeBSD, sponsored by RG Nets.

Ensuring industry visibility to the excellence and impact of FreeBSD is vital to ensuring tier one support for FreeBSD across all key hardware and software platforms. As a community, every conversation we have with people outside the BSD communities, and every piece of content we publish, that attest to how FreeBSD powers our individual and corporate success, brings us one step closer.

To this end, the Foundation is working on a FreeBSD Impact Report that will aggregate the core and often mission critical role FreeBSD plays in society, from embedded systems powered by QNX, to payments and check processing, to digital entertainment, internet and cybersecurity infrastructure.

Our community is stepping up in innumerable ways, including to make sure FreeBSD supports industry-standard containerized workloads — check out the Open Container Initiative FreeBSD runtime extension working group.

The recently opened hardware vendor support survey will feed into a hardware support guide that reflects the collective experience of all respondents that is intended to help everyone identify hardware vendors that prioritize FreeBSD; it will also help focus Partnerships' outreach on the priority vendors.

To close, please TELL THE WORLD YOU USE FREEBSD AND WHY. There is no wrong way to do this — put it on your blog, on your favorite social media channel, list FreeBSD on your company’s Open Source page, contact the Foundation about a Case Study, etc.

Stormshield, a leading cybersecurity company based in Europe, provides a great example of how vendors that use FreeBSD can do this. The footer of their blogs says: "A strong supporter of Open Source, Stormshield is an active member (and sponsor) of the FreeBSD community…​Whenever we modify Open Source software, make patches or add features, we offer them to the community for inclusion."


The first quarter of 2024 marked the beginning of a new era for the Foundation Advocacy team. We welcomed Kim McMahon in the role of Senior Director of Advocacy and Community and also brought on two new technical writers to help increase the frequency and depth of the FreeBSD-related content we produce. Just some of our expanded Q1 efforts to support FreeBSD are below.


Thank you to everyone who gave us a financial contribution last quarter to help fund our work to support the Project. 2024 started strong with a total of $250,855 raised this quarter. We are grateful for your investment in FreeBSD!

Please consider supporting our efforts in 2024 by making a donation here:

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 to find more about how we support FreeBSD and how we can help you!

FreeBSD Release Engineering Team

Contact: FreeBSD Release Engineering Team, <>

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.

During the first quarter of the year, the Team managed 13.3-RELEASE, leading to the final RELEASE build and announcement in March. Planning has started for the upcoming 14.1-RELEASE cycle.

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

Cluster Administration Team

Contact: Cluster Administration Team <>

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

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

  • Regular support for user accounts.

  • Regular disk and parts support (and replacement) for all physical hosts and mirrors.

  • Set up a new mirror in Chicago.

FreeBSD Official Mirrors Overview

Current locations are Australia, Brazil, Germany, Japan (two full mirror sites), Malaysia, South Africa, Sweden, Taiwan, United Kingdom (full mirror site), United States of America — California, Chicago, New Jersey (primary site), and Washington.

The hardware and network connection have been generously provided by:

New official mirrors are always welcome. We have noted the benefits of hosting single mirrors at Internet Exchange Points globally, as evidenced by our existing mirrors in Australia, Brazil, and South Africa. If you are affiliated with or know of any organizations willing to sponsor a single mirror server, please contact us. We are particularly interested in locations on the United States West Coast and throughout Europe.

See generic mirrored layout for full mirror site specs and tiny-mirror for a single mirror site.

Continuous Integration

Contact: Jenkins Admin <>
Contact: Li-Wen Hsu <>
Contact: freebsd-testing Mailing List
Contact: IRC #freebsd-ci channel on EFNet

In the first quarter of 2024, we worked with the project contributors and developers to address their testing requirements. Concurrently, we collaborated with external projects and companies to enhance their products by testing more on FreeBSD.

Important completed tasks:

  • With help from clusteradm, the host running test VMs had disk and memory upgraded by reusing the parts of decommissioned machines.

  • Update the build environment of stable/13 jobs to 13.3-RELEASE.

  • Turn i386 build on main branch to use cross build on amd64.

Work in progress tasks:

  • Merging

  • Merging

  • Adding new hardware purchased by the FreeBSD Foundation to the CI cluster

  • Designing and implementing pre-commit CI building and testing and pull/merge-request based system (to support the workflow working group)

  • Proof of concept system is in progress.

  • Designing and implementing use of CI cluster to build release artifacts as release engineering does, starting with snapshot builds

  • Simplifying CI/test environment setting up for contributors and developers

  • Setting up the CI stage environment and putting the experimental jobs on it

  • Redesigning the hardware test lab and adding more hardware for testing

Open or queued tasks:

  • Collecting and sorting CI tasks and ideas

  • Setting up public network access for the VM guest running tests

  • Implementing use of bare-metal hardware to run test suites

  • Adding drm ports building tests against -CURRENT

  • Planning to run ztest tests

  • Helping more software get FreeBSD support in its CI pipeline (Wiki pages: 3rdPartySoftwareCI, HostedCI)

  • Working with hosted CI providers to have better FreeBSD support

Please see freebsd-testing@ related tickets for more WIP information, and do not hesitate to join the effort!

Sponsor: The FreeBSD Foundation

Ports Collection

Contact: Tobias C. Berner <>
Contact: FreeBSD Ports Management Team <>

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.

According to INDEX, there are currently 32,244 ports in the Ports Collection. There are currently ~3,300 open ports PRs. The last quarter saw 12,991 commits by 158 committers on the main branch and 888 commits by 61 committers on the 2024Q1 branch. Compared to last quarter, this means a large increase in the number of commits on the main branch (up from 9,424) and slightly more backports to the quarterly branch (up from 781). The number of ports also increased (up from 31,942).

In Q1 there were around 14,127 commits to main: The most active committers were:

  • 2934 sunpoet

  • 2676 bofh

  • 1297 yuri

  • 748 eduardo

  • 545 jbeich

  • 347 arrowd

  • 233 diizzy

  • 195 yasu

  • 170 ehaupt

  • 164 wen

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

  • pkg 1.21.0

  • New USES: ocaml

  • Default version of gcc switched to 13

  • Default version of ruby switched to 3.2

  • Default version of lazarus switched to 3.2.0

  • Default version of go switched to 1.21

  • Chromium updated to 123.0.6312.105

  • Electron-28 updated to 28.2.10

  • Electron-27 updated to 27.3.9

  • Firefox updated to 124.0.2

  • Firefox-esr updated to 115.9.1

  • KDE updated to Frameworks 5 5.115, Frameworks 6 to 6.0.0 Plasma Desktop 5 to 5.27.11, Plasma Desktop 6 to 6.0.2

  • Qt5 updated to 5.15.13

  • Qt6 updated to 6.6.3

  • Python updated to 3.11.9, 3.10.14 and 3.8.10

  • Ruby updated to 3.2.3

  • Rust updated to 1.77.0

  • SDL updated to 2.30.2

  • Sway updated to 1.9

  • wlroots updated to 1.17.2

  • Wine updated to 9.0

  • Xorg server updated to 0.17.2

During the last quarter, FreeBSD Packages Management Team ran 17 exp-runs to test various ports upgrades, updates to default versions of ports, subpackage support and base system changes.


Projects that span multiple categories, from the kernel and userspace to the Ports Collection or external projects.

Audio Stack Improvements

Contact: Christos Margiolis <>

The FreeBSD audio stack is one of those fields that does not attract the same attention and development as others do, since it has been left largely unmaintained, and, although high in quality, there is still room for improvement — from lack of audio development frameworks, to missing userland utilities and kernel driver-related bugs. This project is meant to touch on all those areas, and as such, is more of a general improvement project, than an implementation of a specific feature.

So far, my focus has been towards the kernel side of the audio stack, with D43545 being probably the most requested and notable patch. I am also working on scrapping the rather outdated "snd_clone" audio device cloning framework of sound(4), and replacing it with DEVFS_CDEVPRIV(9) (D44411).

Some of the future tasks include:

A more detailed description can be found here.

You can also follow the development process in freebsd-multimedia@, where I post regular reports:

Sponsor: The FreeBSD Foundation

Bhyve Improvements

Contact: Chris Moerz <>

Bhyve I/O Performance Measurements

Participants of the weekly bhyve production users calls recently discussed bhyve’s I/O performance. Various ways of measuring and comparing were brought up, however it was quickly clear that there is currently no formal analysis and report on this. So, we started this effort in the hopes of better understanding the various impacts of configuration options for a guest on its I/O performance. We created a set of shell scripts that harness a FreeBSD guest for running benchmarks/fio I/O performance measurements under various configurations. This allows us to compare multiple criteria like bandwidth, latency, IOPS, and more.

So far, we are testing for

  • different storage backends (i.e. ahci-hd, nvme, virtio-blk)

  • different memory settings

  • different CPU pinning options

  • different block sizes for the backing storage

  • different block sizes for accessing virtual disks

We are also pitting results for different CPU manufacturers against each other and contrasting guest vs host performance to better understand the performance impact of virtualization.

We plan to continue discussing our results during Michael Dexter’s weekly bhyve production users call - come join us if you are interested. We also hope to be able to present the results at EuroBSDCon in Q3.

Bhyve Virtual Machine Tooling

Last year, Greg Wallace at the FreeBSD Foundation founded the Enterprise Working Group with the specific goal of addressing pain points of Enterprise users of FreeBSD. One of the work groups that emerged clustered around bhyve and jails management tooling. After collecting a set of desired features and functionality, one overarching key point for bhyve emerged: the desire to have configuration concepts and tooling for bhyve like the ones available for jails.

While other desirable features were identified as well, i.e. TPM software emulation and snapshot/restore/host-migration, the conceptual tooling question won over those due to the lower degree of complexity and its clarity on goal and the path on how to take steps towards it.

Technically, this means working out existing gaps around process supervision and virtual machine state management. First steps were taken by experimenting with existing frameworks (i.e. s6rc work by Jan Bramkamp) and eventually — through discussions in the weekly bhyve production user’s calls (organized by Michael Dexter) — this led to a proof-of-concept implementation of "vmstated".

Started as an experiment to better understand the problem space of process supervision and virtual machine state handling, vmstated is constructed of a daemon and vmstatedctl management utility. It is built with base-only tooling and libraries and leverages FreeBSD specific constructs like kqueue to minimize its resource impact.

vmstated is configured via a UCL configuration file (similar to jails.conf) and — in combination with a bhyve_config(5) configuration file — already provides highest flexibility in configuring virtual machines. vmstatedctl provides a jail-like command set to start, stop, and retrieve status information about guests. State transitions can easily be hooked via shell scripts and allow running additional commands for network or storage set up and tear down when relevant state changes occur.

An initial release is already in ports as sysutils/vmstated and updates are pending commit; however, the newest version can be found on GitHub. We are considering expanding the work; we would also like to invite anyone interested to join us in this work! Patches, suggestions, feedback, etc. are all very much welcome!

If you want to know more about our work, come join us at one of Michael Dexter’s weekly bhyve production users calls or reach me by email.


We managed to update a few parts of the Handbook and Porter’s Handbook (thanks to Ed Maste, Joseph Mingrone, Pau Amma, and Rodney W. Grimes):

  • several improvements and expansions to the virtualization chapter in the FreeBSD Handbook

    • using a bhyve_config(5) configuration file

    • jailing bhyve

    • experimental snapshot and restore feature

    • setting up a Windows guest

  • we also have a review (D43940) up for an initial step to improving the bhyve man page

    • this was intentionally started with a structural update first to separate the many -s flag options

    • once this lands, we can move to a more widespread update to the overall content

Feedback is obviously very welcome — on the existing content as well as any additional content we should be looking into!

Graphical Installer for FreeBSD

Contact: Pierre Pronchery <>

The first hurdle to overcome when testing a new Operating System is to get it installed. What is more, the first impression new users gather from an Operating System is its installation process. The state of the art for Operating System installers nowadays definitely involves a graphical process. This is the case for mainstream systems but also for other UNIX systems comparable to FreeBSD: RedHat Enterprise Linux, Ubuntu, Debian GNU/Linux, or even Devuan GNU+Linux Regardless of the technical level of the actual user, this is how the platform will be compared in the public eye.

In practice, FreeBSD has already been derived as a desktop-oriented Operating System by different projects. Of these, I only found GhostBSD as a maintained project offering a graphical procedure to install the system. The objective here was to consider a procedure that FreeBSD could adopt as part of its base system, in order to ship a graphical installer much like the current installer. However, GhostBSD’s installer relies on a Gtk+ interface driven with Python, implying a hefty footprint on the installation media when adopting FreeBSD’s usual image generation procedure. It would also imply importing and maintaining new projects into the ports tree.

Instead, with knowledge of the current bsdinstall(8) and bsdconfig(8) utilities, I envisioned a BSD-licensed replacement for Xdialog(1). Just like when invoking bsdconfig with the -X switch for graphical mode, it could be dropped in instead of bsddialog(1) and allow graphical installation - while sharing the infrastructure of the current installer. To avoid confusion with the current implementation of Xdialog from the x11/xdialog port, I have named its replacement gbsddialog(1). It also has to be said that Xdialog is quite obsolete (latest release in 2006) and this shows visually too.

After creating a Proof-of-Concept prototype past the 14.0 release, I was provided with a 2-months window by the FreeBSD Foundation, in order to complete a working implementation. Thanks to a few shortcuts, I was glad to present the outcome of this effort during the WIP session of AsiaBSDCon 2024, including a working graphical installer.

Most of the necessary patches are already available for review in FreeBSD’s Phabricator:

I have tried to keep these patches in growing order of friction expected before integration.

The most important objective of this project was to improve bsdinstall, regardless of the success of this integration. From the items above, it should be noted that D44279, D44280, D44670 are expecting to improve the general look & feel of the installer, even while in text mode. Similarly, D44671 and D44672 improve the overall versatility of the installer when scripted or customized. D44673 and D44674 bring it on par with bsdconfig -X, even allowing the graphical installation of jails.

Some parts are still missing, or made use of shortcuts still unsuitable for integration:

  • The "fetchmissingdists" target was avoided by shipping every component on the installation media;

  • The "checksum" and "extract" targets had to be re-implemented with simpler code, degrading the user experience also with the regular installer;

  • Creation of the installation media generates an additional, heavy image (almost 8 GB), and is suspected to be hindered by a bug in makefs(8).

The corresponding code can be found in my GitHub fork in the khorben/bsdinstall-graphical4 branch. As can be guessed from the branch name, depending on the complexity of rebasing operations, combined with the (hopefully) progressive integration of the changes proposed, new branches may be added to keep track of the progress. (In fact a khorben/bsdinstall-graphical5 branch already exists.)

Still, a lot needs to be done for the installer to reach a new level of maturity overall. While working on this project, I have received general complaints on the installer, and calls for a complete rewrite. It is true that the current code base suffers from a number of issues and limitations. The lack of a graphical installer is one of many symptoms, which range from the lack of recovery from errors, of navigability to previous steps, of a general vision of the installation progress, or of a network-based installer. In the meantime, this is the installer we have and are familiar with, and I think it can still be saved and improved.

Special thanks go to Ed Maste and Joe Mingrone for the opportunity, and to Philippe Audeoud, Tobias C. Berner, Olivier Certner, Jessica Clarke, Olivier Cochard-Labbé, Baptiste Daroussin, Brad Davis, Michael Dexter, Li-Wen Hsu, Mateusz Piotrowski, Alfonso Siciliano, Emmanuel Vadot, and Robert Watson for the feedback, reviews, and encouragements. (If I missed anyone, you know I did not mean to!)

Sponsor: The FreeBSD Foundation


Changes affecting the base system and programs in it.


Contact: Brooks Davis <>

The libsys project removes direct system calls from and (aka to a separate This will:

  • Isolate language runtimes from the details of system call implementations.

  • Better support logging and replay frameworks for systems calls.

  • Support elimination of the ability to make system calls outside trusted code in the runtime linker and libsys.

This work was initially inspired by a compartmentalization prototype in CheriBSD in 2016. Ali Mashtizadeh and Tal Garfinkel picked that work up and attempted to upstream it (D14609). Unfortunately we could not figure out how to review and land the massive reorganization required through a phabricator review so it languished. Last year the CHERI project once again found a need for system call separation in a new library-based compartmentalization framework in CheriBSD so I rebuilt the patch from scratch, committing dozens of libc cleanups along the way. I landed the first batch of changes on February 5th. Since then I have made a number of refinements to the way we link libsys as well as which symbols are provided in which library.

Thanks to Konstantin Belousov for many rounds of review and feedback as well as runtime linker fixes. Thanks to Mark Johnston for runtime linker debugging and Dimitry Andric for sanitizer fixes. Thanks also to everyone who reported bugs and helped debug issues.

Known issues (as of the end of the reporting period)

  • The libsys ABI is not yet considered stable (it is safe to assume __sys_foo() will be supported so language runtimes can use it now).

  • Programs using the address sanitizer must be linked with -lsys (resolved in base at publication time).


  • Add a libsys.h. (See D44387 and other reviews in the stack.)

  • Update intro(2) for libsys.

  • Finalize the ABI. I am likely to reduce the set of _ (underscore) prefixed symbols we expose.

  • MFC the existence of libsys? It is not clear this is practical, but it might be possible to MFC something useful for language runtimes.

Help wanted

  • Port language runtimes that do not use libc to use libsys for system calls rather than rolling their own interfaces.

  • Explore limitations on where system calls can be made similar to OpenBSD’s msyscall(2) (now obsolete) and pinsyscalls(2) (not an obvious match to our libsys).

Sponsor: AFRL, DARPA

PackageKit backend for FreeBSD pkg

Contact: Gleb Popov <>

PackageKit is a small D-Bus daemon program that serves as a backend for "application store" type of apps - most notably Plasma Discover and Gnome Software Center. The latest PackageKit release features a libpkg backend, which means that you can now use PackageKit-enabled programs on FreeBSD to manage software. Plasma Discover is already switched to using PackageKit, so you will get it working out of the box once you update your ports/packages.

If you observe any crashes or bugs in PackageKit please let me know by opening an issue upstream. If you are interested in contributing, there is a lot of work to do too!

Sponsor: Serenity Cybersecurity, LLC


Updates to kernel subsystems/features, driver support, filesystems, and more.

iwlwifi(4) and wireless for 13.3-RELEASE

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

In the first weeks of 2024 focus was on stability for 13.3-RELEASE to finally make iwlwifi(4) usable. The upcoming 14.1-RELEASE will benefit from this work too. The response has since generally been positive and iwlwifi(4) supporting chipsets up to BE200 seems mostly stable, yet still slow.

A lot of testing was provided by the FreeBSD Foundation and by many users. Massive thanks to everyone who tested, reported back, updated PRs and helped other users.

I have also slowly started to "categorise" more (old) wireless problem reports and will try to continue with some spring cleaning throughout the year.

If you have questions or feedback please use the freebsd-wireless mailing list. That way everyone will see, be able to join in, and the answers will be publicly archived.

Sponsor: (BE200 hardware)


Updating platform-specific features and bringing in support for new hardware platforms.

Ten64, WHLE-LS1, and HoneyComb

Contact: Bjoern A. Zeeb <bz@FreeBSD.ORG>

Solid-Run’s HoneyComb, Traverse Technologies’s Ten64 and some versions of Conclusive Engineering’s WHLE-LS1 all are NXP based platforms with the Data Path Acceleration Architecture Gen2 (DPAA2).

Work has happened to support or improve support for peripherals on these boards.

For DPAA2 I have local changes which will need review (or further discussion):

  • Cleanup of memac (MDIO) code reducing bus attachment (ACPI and FDT specific) code into more common code.

  • Cleanup of MC bus attachment code (again ACPI, FDT).

  • For reasons of mii_fdt.c support on some PHYs on FDT-based platforms restructure MAC/MII code and mostly migrate it out of the network interface (NI).

  • Improve Dmitry Salychev’s (dsl) initial SFF/SFP code, prototyping a bus similar to MII for SFP with the hope that with more work it can grow into a larger, general FreeBSD framework and hooked it up to DPMAC.

  • With this, minimal support (still fairly hacked up) for "managed" SFP+ mode (using the Ten64 terminology) is usable on FDT-based systems using DAC and fiber cables.

  • Add more sysctl statistics to DPMAC and NI.

In short, I mostly cleaned up some of the mess I contributed to during the initial bring-up.

For the LS1088a based WHLE-LS1 systems changes include:

  • device-tree file updates.

  • Added support for the PCA9546 I2C Switch (committed).

  • Added basic support for the PCAL6524 24-bit Fm+ I2C-bus/SMBus I/O expander.

  • Added basic support for the PCA9633 4-bit Fm+ I2C-bus LED driver to drive the status LEDs.

  • Added support to program the rgephy(4) LEDs (which needs to be validated).

  • Started testing the eMMC with MMCCAM and GENERIC but had trouble (needs further investigation, seemed fine from firmware for updates).

  • Tested one of three PCIe slots and USB fine.

For the Ten64:

  • Most of the basic lifting happened a while ago and it has generally been usable.

  • Detecting the VSC8514 PHY as such went in end of last year.

  • Used as the default platform to test the DPAA2 changes and SFP/SFP+ code.

In addition Pierre-Luc Drouin has overhauled the Vybrid I2C support now attaching and working on both FDT- and ACPI-based systems (committed).

Sponsor: Traverse Technologies (Ten64 hardware a while ago, support)


Updating cloud-specific features and bringing in support for new cloud platforms.

FreeBSD on Microsoft HyperV and Azure

Contact: Microsoft FreeBSD Integration Services Team <>
Contact: freebsd-cloud Mailing List
Contact: The FreeBSD Azure Release Engineering Team <>
Contact: Wei Hu <>
Contact: Souradeep Chakrabarti <>
Contact: Li-Wen Hsu <>

In this quarter, we have solved all the blocking issues and published the 13.3-RELEASE on Azure Marketplace.

Work in progress tasks:

  • Automating the image building and publishing process and merging to src/release/.

  • Building and publishing snapshot builds to Azure community gallery.

The above tasks are sponsored by The FreeBSD Foundation, with resources provided by Microsoft.

Open tasks:

Sponsor: Microsoft for people in Microsoft, and for resources for the rest
Sponsor: The FreeBSD Foundation for everything else

FreeBSD as a Tier 1 cloud-init Platform

Contact: Mina Galić <>

cloud-init is the standard way of provisioning servers in the cloud. Over the past year and a half, thanks to this FreeBSD support has steadily improved. This year, together with cloud-init developers and the FreeBSD Foundation, we decided to explicitly focus on making improvements in FreeBSD itself, that will aid the cloud-init team to test future changes to FreeBSD code-paths themselves. To achieve this goal, I need to make FreeBSD run in LXD (and Incus), under the control of lxd-agent (or incus-agent).

Here are some improvements from the recent weeks:

The work to come, in broad strokes:

  • Finish the FreeBSD VirtIO Socket driver.

  • Fix Go’s runtime to support VirtIO on FreeBSD.

  • Port lxd-agent’s dependencies to FreeBSD.

  • Port lxd-agent to FreeBSD.

That work will be interspersed with more improvements to cloud-init on BSDs, and more tests on different cloud providers.

Sponsor: The FreeBSD Foundation

OpenStack on FreeBSD

Contact: Chih-Hsin Chang <>
Contact: Li-Wen Hsu <>

The OpenStack on FreeBSD project aims to seamlessly integrate OpenStack cloud infrastructure with the FreeBSD operating system. It uses FreeBSD’s unique features while ensuring compatibility with OpenStack standards.

In the first quarter of 2024, we made significant progress on the OpenStack on FreeBSD project. This included submitting a proposal for BSDCan 2024 and attending AsiaBSDCon 2024 to share our porting experiences and gain exposure for the project. The feedback received at AsiaBSDCon was particularly valuable and helped in refining the project’s direction. During this period, we also reviewed the project’s phase 1 tasks and made necessary adjustments. We also planned for phases 2 and 3, aligning them with the project’s long-term goals. One technical achievement was verifying the functionality of bhyve serial console over TCP, an important part of the project’s infrastructure. Additionally, we created a demo video showcasing the project’s progress and features.

Looking ahead, our focus for the next quarter includes confirming the feasibility of implementing FreeBSD privilege-management user space tools leveraging mac(4) and priv(9), simplifying installation steps by transitioning to FreeBSD ports, and porting OpenStack Ironic to FreeBSD. These tasks will enhance the project’s capabilities and compatibility.

Sponsor: The FreeBSD Foundation


Noteworthy changes in the documentation tree, manual pages, or new external books/documents.

Documentation Engineering Team

Contact: FreeBSD Doceng Team <>

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.

During the last quarter:

Edward Tomasz Napierała's doc commit bit was taken for safekeeping. Tom Rhodes's doc commit bit was taken for safekeeping.

FreeBSD Translations on Weblate

Q1 2024 Status
  • 17 team languages

  • 189 registered users

Three new translators joined Weblate:

  • piker3 in Polish team (pl)

  • chrislongros in Greek team (el)

  • grip in Italian team (it_IT)

  • Chinese (Simplified) (zh-cn) (progress: 7%)

  • Chinese (Traditional) (zh-tw) (progress: 3%)

  • Dutch (nl) (progress: 1%)

  • French (fr) (progress: 1%)

  • German (de) (progress: 1%)

  • Greek (el) (progress: 1%)

  • Indonesian (id) (progress: 1%)

  • Italian (it) (progress: 5%)

  • Korean (ko) (progress: 32%)

  • Norwegian (nb-no) (progress: 1%)

  • Persian (fa-ir) (progress: 3%)

  • Polish (progress: 2%)

  • Portuguese (progress: 0%)

  • Portuguese (pt-br) (progress: 22%)

  • Spanish (es) (progress: 36%)

  • Turkish (tr) (progress: 2%)

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.


Changes affecting the Ports Collection, whether sweeping changes that touch most of the tree, or individual ports themselves.

FreshPorts: Notification of new packages

Contact: Dan Langille <>

FreshPorts and FreshSource have reported upon FreeBSD commits for 20 years. They cover all commits, not just ports.

FreshPorts tracks the commits and extracts data from the port Makefiles to create a database of information useful to both port maintainers and port users.

For example, shows the history of the security/ port, back to its creation in May 2017. Also available are dependencies, flavors, configuration options, and available packages. All of this is useful for both users and developers of ports.

Notification: New Package Available

One of the original features of FreshPorts is notification of ports updates. You can create a list of ports and receive notifications about those ports. This new feature can also notify when a new package is available for that port. The use case: a known security vulnerability has been patched. FreshPorts will tell you the port has been patched, and then you wait for the package. This new feature will tell you when that package is available.

Details at:

Help Needed

It has been over 23 years since FreshPorts started. Others must take over eventually. I have started that process recently. There are several aspects to FreshPorts:

  • FreeBSD admin (updating the OS and packages)

  • front end code (website - mostly PHP)

  • back end code (commit processing - Perl, Python, shell)

  • database design (PostgreSQL).

The database does not change very often and requires little maintenance compared to the applications and OS. The website pretty much runs itself. From time to time, a change to the FreeBSD ports infrastructure breaks something or requires a modification, but there is rarely any urgency to fix that. This is not a huge time commitment. There is a lot of learning. While not a complex application, FreshPorts is also not trivial.

To contribute, please join the mailing list and let us know what you would like to help with.

GCC on FreeBSD

Contact: Lorenzo Salvadore <>

Updating GCC default version to 13 is finally finished. Thanks to Antoine Brodin who ran the exp-runs and to all other developers and ports maintainers involved.

As promised in the preceding report, the next goal is to reduce the number of open bugs for GCC ports. Some work on existing bugs has already started.

In particular, lang/gcc14-devel has long stayed out of date due to some issues with building the port without any BOOTSTRAP option. Thanks to the help of other developers and contributors (a special thank to Mark Millard), I noticed that according to the official documentation building GCC without bootstrap requires a working GCC binary and thus I switched lang/gcc14-devel to require that a BOOTSTRAP option is set. However it has later been stated that bootstrapping GCC using clang and libc++ is officially supported. But it has also been stated that this is not a high priority.

At the moment lang/gcc14-devel is the only GCC port requiring a BOOTSTRAP option to be set. The plan is to have all GCC ports for versions greater or equal than 14 (i.e. future GCC ports) to require such an option: even if building without bootstrap is more or less officially supported, being low priority for upstream it increases the burden of maintaining GCC ports for low results. In case lower versions start to have issues building without bootstrap, I am going to require bootstrap for those as well.

Valgrind: port to arm64 on its way

Contact: Paul Floyd <>

The major news, as per the title, is that a port to FreeBSD arm64 (or aarch64) is now ready. The next steps are to get it reviewed and pushed upstream.

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

devel/valgrind-devel will get an update as soon as I have pushed the changes for arm64.

--track-fds=yes now checks for and warns about attempts to close a file descriptor more than once. Handling of closefrom has been improved to use this feature.

There are some important fixes for FreeBSD 15, in particular handling the new libsys.

Here is a list of smaller bugfixes:

  • Support for FreeBSD 13.3 has been added.

  • Added a redirect for reallocarray.

  • Several fixes for aio* functions.

  • Added a redirect for memccpy.

  • There is a fix for _umtx_op OP_ROBUST_LISTS.

  • Added redirects for C23 free_sized and free_aligned_sized.

  • Correctly propagate the ELF stack protection flags to the guest stack that Valgrind synthesizes.

  • Fixes for --sanity-level-3 and above (only used for Valgrind self-testing at runtime).

  • Several fixes to checking done for semctl.

  • Fixed argument checking for utrace.

  • Fixed argument checking for clock_nanosleep.

Third Party Projects

Many projects build upon FreeBSD or incorporate components of FreeBSD into their project. As these projects may be of interest to the broader FreeBSD community, we sometimes include brief updates submitted by these projects in our quarterly report. The FreeBSD project makes no representation as to the accuracy or veracity of any claims in these submissions.

Containers and FreeBSD: Pot, Potluck and Potman

Contact: Luca Pizzamiglio (Pot) <>
Contact: Bretton Vine (Potluck) <>
Contact: Michael Gmelin (Potman) <>

Pot is a jail management tool that also supports orchestration through Nomad. Potluck aims to be to FreeBSD and Pot what Dockerhub is to Linux and Docker: a repository of Pot flavours and complete container images for usage with Pot and in many cases Nomad.

During this quarter, there were no new Pot releases.

Potluck saw quite some activity though. Not only have the images been rebuilt for FreeBSD 14, but also the new Adminer container has been submitted by first-time contributor Sidicer. Additionally a large number of additional features, updates and fixes have been committed to containers like HAProxy-Consul, Grafana, PostgreSQL-Patroni, or Prometheus.

For the Mastodon container, a blog post has been published explaining how to use it to run your own instance.

As always, feedback and patches are welcome.

Sponsors: Nikulipe UAB, Honeyguide Group

Last modified on: April 25, 2024 by Lorenzo Salvadore