index | | raw e-mail
• Added support for VLAN tagging for Jails directly instead of requiring
users to create a separate bridge for each VLAN.
• A lot of manual command-line flags have now been converted into libvirt XML
syntax for VMs, allowing easier management and better compatibility with
libvirt-based tools.
• Significant improvements have been made to the auto-start/stop processes
for VMs and Jails.
General
• Notifications system has been re-worked to add support discord webhooks,
ntfy.sh and SMTP based transports, it now also supports multiple transports
at once, and allows users to configure which events they want to receive
notifications for.
Roadmap Update
• All the road map items (except NFS shares from the previous quarter) have
been completed, and we are now working on the next set of features for Q3:
• NFS shares support, allowing users to create and manage NFS shares directly
from the Web UI.
• A simplified UI-mode aiming to make it easier for new users to get started
with Sylve as a NAS appliance.
• Podman and OCI container support, allowing users to run containers
alongside VMs and (classic) Jails.
• A mobile application for iOS and Android, allowing users to manage their
clusters on the go.
• App template library, allowing users to easily deploy popular applications
(like Nextcloud, Plex, etc.) with a single click.
Sponsors: The FreeBSD Foundation, Alchemilla Ventures (Development), IPTechnics
LLC (Infrastructure & Testing)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Hackathon 202606 — Halifax, Nova Scotia, Canada
Links:
Hackathon/202606 Wiki Page URL: https://wiki.freebsd.org/Hackathon/202606
FreeBSD Hackathon Wiki Page URL: https://wiki.freebsd.org/Hackathon
Contact: Joe Mingrone <jrm@FreeBSD.org>
After BSDCan 2026 in Ottawa, some members of the community gathered for a
hackathon at Dalhousie University in Halifax, Nova Scotia, Canada. Across the
three repositories, 93 commits landed with the tag Event: Halifax Hackathon
202606.
Much of this work is described in separate report entries, but here is a
high-level summary. The bulk of the src work focused on CPU power management.
Most of it landed in hwpstate_intel(4), which received fixes for several MSR
and uninitialized variable bugs, moved the energy performance preference to an
8-bit scale, and replaced thread_lock() and sched_bind() with IPIs. A new
cpu_get_pcpuid() KPI was also added and adopted by both hwpstate_intel(4) and
hwpstate_amd. A sweep through the ACPI code tightened the types of the sleep
and wake event handlers, removed unused disable flags from acpi_cpu, acpi_hpet
(4), and acpi_timer, and made the kernel refuse S4 when S4BIOS is not
supported. For laptop support, a new hrfkill driver was committed for the
airplane key on some Framework laptops, evdev reporting of the microphone mute
key was added to acpi_ibm(4), and iichid(4) was changed to always release its
interrupt resource. Other src commits touched libusb, libdtrace, libcxxrt,
ifconfig(8), sched_ule, and a number of manual pages. In ports, the default
Python was switched to 3.12, a new databases/py-oracledb port was added, and a
sysutils/consolekit2 change enabled S0ix suspend on 16-CURRENT. The Emacs ports
received various updates and improvements; the R, Jenkins, and some
bioinformatics ports were updated. The documentation work added a Handbook
section on ZFS native encryption, updated the geli encrypted swap instructions,
and improved the FDP Primer guidance on generating patches with context.
Here are the raw hackathon commits across the doc, ports, and src repositories.
While most of the time was spent hacking, it was not all work, as the photos
show. Participants spent some evenings and half a day on fun.
Sponsor: The FreeBSD Foundation (meal)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Parthenope — Current Status and Improvements
Links:
BSDCan 2026 Presentation Slides
Contact: Alfonso Sabato Siciliano <asiciliano@FreeBSD.org>
Parthenope is a modular, two-step installer for FreeBSD, written in Lua.
During this quarter, the project was presented at BSDCan 2026, showcasing its
current status, recent improvements, and future directions. The presentation
also introduced several new ideas, mockups, and proof-of-concept
implementations for future discussion and development, including an out-of-box
experience and/or a post-installation configuration workflow.
Since the previous status report and the EuroBSDCon 2025 presentation, several
core parts of the installer have been completely refactored or rewritten,
including:
• The configuration file;
• The communication file used to exchange data between Step 1 and Step 2;
• The installer subsystems, including internationalization, multi-mode
support, and related infrastructure;
• The Step 1 and Step 2 managers;
• The component framework, where installation screens are now managed and
invoked by the Step 1 Manager;
• Multiple installer components and installation screens.
The Text User Interface (TUI) frontend is now close to feature-complete,
bringing it close to supporting a complete FreeBSD installation. The remaining
major components and screens are the partition editor, ZFS configuration, boot
configuration, and the network manager.
While it is not yet possible to fully install FreeBSD using Parthenope,
development is progressing rapidly toward a functional release. The next steps
are:
• Complete the remaining TUI installer components and screens.
• Implement the Command Line Interface (CLI) frontend to improve
accessibility.
• Develop the Web frontend to enable installation via a web browser.
Parthenope started as a personal project, but it continues to grow thanks to
community ideas, feedback, and feature requests, which are always welcome.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Native S.M.A.R.T. data retrieval in FreeBSD
Links:
S.M.A.R.T. on GitHub URL: https://github.com/ctuffli/smart
Contact: Chuck Tuffli <chuck@freebsd.org>
FreeBSD has imported a native Self-Monitoring, Analysis, and Reporting
Technology (S.M.A.R.T.) utility, smart(8), into the base system, providing
lightweight, built-in disk health monitoring capabilities without requiring
third-party packages. It was inspired by the diskctl(8) framework proposed at
AsiaBSDCon 2016 to create a permissively-licensed S.M.A.R.T. utility addressing
licensing and functionality gaps in existing tools.
The utility provides a unified interface for retrieving S.M.A.R.T. data across
multiple storage protocols, including ATA, NVMe, and SCSI. It focuses on ease
of integration with monitoring tools, providing multiple output formats
(tab-delimited fields, JSON, XML) via libxo(3) and allowing users to query
specific health attributes.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Userland
Changes affecting the base system and programs in it.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Process Descriptor API completion 2
Contact: Konstantin Belousov <kib@FreeBSD.org>
Links:
sys: add pdopenpid(2) URL: https://reviews.freebsd.org/D57124
link pddupfd(2) https://reviews.freebsd.org/D57163
Following the addition of pdwait(2) and pdrfork(2) system calls, I looked at
the other missing features that are requested by application programmers. The
largest feature asked for seems to be an ability to obtain a process descriptor
for an existing process.
Currently only one file descriptor may reference an internal struct procdesc in
kernel, which in part explains why the interface to open the process by pid is
not yet done. The work added the ability for procdescs to be pointed to by more
than one file. Attributes controlling the procdesc behavior, e.g. the daemon
(closing the file does not terminate the process) were moved from procdesc to
the file.
This change allowed to extend the procdesc internal interfaces to implement the
man:pdopenid(2) system call.
A facility implemented e.g. by the Linux pidfd descriptors is the pidfd_getfd()
system call, that duplicates specified file descriptor from the target process,
into the caller. The implementation of it for FreeBSD, named man:pddupfd(2) is
relatively straightforward once we get the fget_remote(9) helper.
A problem with it started when the algorithm to check for privileges required
to allow the operation was developed. The kernel checks the result of
p_candebug() to see if something should be allowed that directly accesses
programming resources of the remote process. But p_candebug() result is only
valid while the target process lock is owned. Besides, p_candebug() denies
actions if the target process changes the executing program with man:execve(2),
which might change the privileges of the process if the image is set-uid or
set-gid. Overall, this makes the plain check with p_candebug() inadequate,
because we cannot own the process lock over fget_remote().
For that, a facility was developed that provides mutual exclusion for execing
in the target process vs. the caller, called execblock. Also, helpers to
reference the current vmspace for a process were added, to avoid using
execblock when only a consistent target address space is required for the
action, like reading of the process strings or copying the process memory.
Existing places in system that are affected by the race were identified, and
the usage of execblock or vmspace referencing interfaces applied as needed.
Then, the man:pddupfd(2) was implemented with the help of fget_remote() and
execblock.
Sponsor: The FreeBSD Foundation
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Scheduler
Links:
DevSummit Wiki page URL: https://wiki.freebsd.org/DevSummit/202606
Slides URL:
https://wiki.freebsd.org/DevSummit/202606?action=AttachFile&do=view&target=Scheduler.pdf
Contact: Olivier Certner <olce@FreeBSD.org>
Ongoing work is happening in the area of schedulers along multiple axes.
We are working on solutions to long-standing shortcomings in the ULE scheduler
such as unfairness for non-interactive threads in certain particular
circumstances and the very weak effect of nice values. It seems difficult to
solve the first in full with ULE’s current design, so in parallel we have been
sketching a new design with the following additional aims:
1. More stable and predictable behavior.
2. Separately controllable latency and allocated CPU.
3. Enabling new features like scheduling on hybrid CPUs, power-aware
scheduling, hierarchical scheduling, etc. while retaining fairness.
We have also been reviewing the 4BSD and ULE schedulers in detail, leading to
some bug fixes, such as:
• Priority conflation of differently-niced CPU-bound threads (4BSD)
• Priority diminishing too slowly when consuming CPU, because of some
obsolete SMP scaling (4BSD)
• Fix off by one in preempt_thresh parameter definition (ULE)
• Fix selecting lowest priority thread early in some corner cases (ULE)
• Stop consuming memory linearly with MAXCPU for local runqueues (4BSD; by
Minsoo Choo).
A presentation was done at BSDCan 2026’s Developer Summit on these matters (see
link at the top).
On the hybrid scheduling front, a number of reviews have been created by Koine
Yuusuke with code to support Intel Hardware Feedback Interface (HFI) and Thread
Director (ITD), and a common infrastructure for capacities and scores was
proposed by Minsoo Choo. We will review and shepherd these submissions.
Sponsor: The FreeBSD Foundation
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Kernel
Updates to kernel subsystems/features, driver support, filesystems, and more.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Suspend/Resume Improvements
Links:
Blog URL: https://obiw.ac/s0ix/
BSDCan talk on s2idle/S0ix URL: https://youtu.be/RCjPc4X2Edc
Working branch URL: https://github.com/obiwac/freebsd-s0ix/pull/15
Contact: 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.
Mostly, the status is the same as the previous quarter — work is still ongoing
on narrowing down the NVMe resume issues and fixing up the D-state issues.
The generic power management interface has been committed and zzz(8) has been
rewritten to make use of it. You are now expected to use the
kern.power.supported_stype sysctl to list supported generic sleep types and set
the kern.power.suspend sysctl to the sleep type you would like zzz(8) to use.
A bunch of small fixes and improvements were made to the acpi_spmc driver.
Generic USB4 NHI support has also been committed. The only thing left to commit
for the USB4 support required for S0i3 entry is the suspend routine itself. The
thunderbolt(4) manpage has been updated to be clearer on the fact that this is
only intended to support S0i3 entry.
A manpage has been written for amdsmu(4) to better explain how to diagnose S0i3
entry.
Sponsor: The FreeBSD Foundation
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Hibernate (aka Suspend-to-disk)
Links:
Image saving prototype URL:
https://github.com/OlCe2/freebsd-src/tree/oc-hibernate
EFI loader URL: https://github.com/OlCe2/freebsd-src/tree/for_kib-hiber
Contact: Olivier Certner <olce@FreeBSD.org>
Contact: Konstantin Belousov <kib@FreeBSD.org>
Work is ongoing to have FreeBSD support hibernate (suspend-to-disk), without
BIOS/firmware assistance to save the current machine state, for amd64
UEFI-booted machines. See also the previous report.
After a pause of almost two months, we fixed some bugs in the image saving
prototype, rebased it on recent code, and revised the interface between the
kernel and the resume EFI loader, requiring some changes on both sides. This
lead to a number of changes in ACPI general suspend/resume code and in-passing
fixes. Work is in progress in the EFI loader (stage 1). A sketch of the kernel
resume part (stage 2) was devised.
Some more discussion happened about how to save the system image while
preserving its consistency, as the dump operation itself modifies kernel
memory. The aim is to narrow down which components can interfere with the dump,
and how to prevent that interference. In particular, it appears that low-level
DMA and IOMMU code could perform memory allocations in certain circumstances,
and it is yet unclear if that could happen during a dump. Once determined, we
will pursue eliminating these circumstances if possible, else will work on a
snapshot-like mechanism. Beyond that aspect, a live snapshot mechanism could be
beneficial as it allows to use any kernel facility without restriction to
perform the dump, and in particular alleviates the need to have one dump
routine per disk driver.
We presented the current status of this work, associated challenges and
possible implementation of a snapshot-like mechanism at BSDCan in June, and
will do so again at EuroBSDCon in September.
Sponsor: The FreeBSD Foundation
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Collaborative Processor Performance Control (CPPC)
Contact: Olivier Certner <olce@FreeBSD.org>
Contact: ShengYi Hung <aokblast@FreeBSD.org>
Collaborative Processor Performance Control (CPPC) is a standard introduced by
ACPI to allow the OS to manage performance and efficiency levels of CPUs thanks
to an abstract performance scale in general uncorrelated to, and more
fine-grained, than mere frequency levels.
Work is ongoing again after another kickoff during the Halifax Hackathon at the
end of June.
In the works are:
• New minimum, maximum and desired performance knobs for the Intel driver (
hwpstate_intel(4)).
• Teach powerd(8) about these knobs, and provide basic policies around them.
• A knob to set the EPP (Efficiency/Performance Preference) for all CPUs at
once, and probably similar ones for the minimum, maximum and desired
performance values.
• Conditional enablement of the CPPC functionality of the AMD driver (
hwpstate_amd(4)) on ACPI’s _CPC table presence. A knob will allow users to
bypass this check, and possibly also whether the CPPC features are reported
by CPUID.
• A global profile knob with predefined values (such as "Balanced",
"Performance", etc.), which sets all other more fine-grained knobs. Setting
a fine-grained knob explicitly will switch the profile to "Custom".
A number of preliminary cleanups and fixes were committed at the end of June.
Sponsor: The FreeBSD Foundation
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
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
2025Q3 URL:
https://www.freebsd.org/status/report-2025-07-2025-09/#_audio_stack_improvements
2025Q4 URL:
https://www.freebsd.org/status/report-2025-10-2025-12/#_audio_stack_improvements
2026Q1 URL:
https://www.freebsd.org/status/report-2026-01-2026-03/#_audio_stack_improvements
Important work since last report:
• sound(4), device drivers, and virtual_oss(8) cleanups, fixes and
improvements.
• sound(4) security fix (SA).
• virtual_oss(8) security fix (commit).
• Introduction of an audio group (GID 43) and use of it in all sound device
nodes (commit).
• Support for the Roland UA-33 USB audio interface.
• virtual_oss(8) service option in the installer.
• kqueue(2) improvements for sound(4), thanks to Goran Mekić
<meka@tilda.center>.
• Better hot-swapping (commit).
• EQ controls for sndctl(8) and mixer(8).
You can also follow the development process on the FreeBSD Foundation’s
status-updates repository, where I post weekly reports.
Sponsor: The FreeBSD Foundation
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
LinuxKPI 802.11 and Native Wireless Update
Links:
Support the MediaTek Wireless cards URL:
https://github.com/FreeBSDFoundation/proj-laptop/issues/66
Support the Realtek Wireless cards URL:
https://github.com/FreeBSDFoundation/proj-laptop/issues/99
LinuxKPI based WiFi and suspend and resume URL:
https://github.com/FreeBSDFoundation/proj-laptop/issues/58
Wireless Problem Reports URL:
https://bugs.freebsd.org/bugzilla/showdependencytree.cgi?id=277512&hide_resolved=1
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.
15.1-RELEASE
Due to real life some of the changes I had hoped to have in 15.1-RELEASE did
not make it anymore (see below). In the end I only updated the man pages for
the various drivers shipping. We also updated the firmware ports as a change in
src.git main had prevented them from building anyway. With that fwget(8) was
also updated for more PCI Ids. Finally I helped making sure the already
fantastically prepared release notes had some extra notes on known issues.
Driver updates
All LinuxKPI based wireless drivers were updated to Linux v7.0 in main and
stable/15. This was not planned originally but it turned out that it was little
churn so it could be done in a good work day. The update includes
• the shipping drivers Intel iwlwifi(4) mvm/mld, Realtek rtw88(4) and rtw89
(4),
• the Mediatek mt76 driver which is a work in progress,
• the three Qualcomm Atheros drivers ath10k, ath11k, and ath12k, which are
TODO, as well as
• the Broadcom brcmfmac, which compiles and loads firmware but is lacking the
cfg80211 compat shim and some netdev work.
LinuxKPI based 802.11 suspend and resume
With drm-kmod 6.12 allowing one of my laptops to suspend and resume I could
finally debug the last bits of LinuxKPI 802.11 suspend and resume and I am
happy to announce that automatic suspend and resume for iwlwifi(4) is in main
and stable/15. Feedback, so far, has been overwhelmingly positive. Sadly I
missed the cut for 15.1-RELEASE so try stable or stay tuned for December.
LinuxKPI 802.11 adjustments
As underlying ground works for Realtek and Mediatek various LinuxKPI 802.11
implementation details were improved:
• chandef / chanctx rework: these are definitions on which channel we are
operating. Rework chandef emulation and how the contexts are updated;
prepare for multiple chanctx, etc.
• TX hardware crypto: the mt7921 would happily work with software crypto but
once hardware crypto offload was enabled we would only receive some packets
but not TX any correct frames anymore. It turned out that depending on key
type the driver would user a different path to the keys and we would set
both keys the same way, essentially overwriting the 1st with the 2nd. Fixed
the argument passed down on the set key call to avoid this problem. This
may also help rtw8x where we had seen occasional problems related to MC
packets but validation is still pending.
• rates: started to fill in and update most of the LinuxKPI 802.11 rate
fields (but one which would only be needed for mt7615). Part of this work
was originally done for rtw8x end of last year with a lot of it
supplemented for Mediatek.
• Fixed a compatibility ordering problem: it turned out that some of the
order of events we had implemented did not fully match the expectations of
some drivers. While we were setup and synched various rate related parts
from net80211 to LinuxKPI 802.11 to the driver, one update came too late,
leaving mt7921 with basic rates. Simply moving the code to be called in a
different order solved the problem to get us 11n and 11ac throughput.
LinuxKPI changes:
In addition to the 802.11 parts in LinuxKPI, there is also general LinuxKPI
infrastructure which needs adjustments.
• PAGE_IS_LKPI_PAGE: this is a project to convert an early day shortcut that
a Linux struct page is 1:1 mapped to a native vm_page into a proper Linux
struct page with a vm_page backing. This is mostly needed for some Mediatek
mt76 drivers, but also drm-kmod can finally undo some FreeBSD specific
hacks after this lands.
• LinuxKPI PCI detach (cleanup) functions: the Mediatek driver would cause a
kernel panic on unload or shutdown. It turned out that the various LinuxKPI
PCI cleanup routines were not fully correct as a comment had already hinted
for one part. We fixed this and also cleaned up some of the file. At the
time of writing the reviews are still pending but we hope to have at least
the essential parts committed soon.
• The LinuxKPI IDR code is used by some Mediatek mt76 drivers but is also
shared with drm-kmod and a bunch of semi-native drivers. Unfortunately the
framework has known problems (as some history showed) and does not match
current expectations anymore. Rewriting this is somewhat tricky due to the
larger impact but we hope have it ready in early 26Q3.
• Improved and added some lindebugfs(4) code in order to be able to use
debugfs for mt7921 debugging.
Realtek rtw8x support
After the updates to Linux v7.0 the problems we had with some chipsets not
being able to associate increased. Both rtw88(4) and rtw89(4) now show various
issues. One additional problem was discovered in that the rtw88(4) driver for
at least one chipset would go off for 6s seconds, essentially letting
authentication run into timeouts. It is not understood yet under which
circumstances this will not happen, as it clearly does not seem to be a problem
under Linux. Sadly it was not possible to debug this in time for 15.1-RELEASE.
We hope to look into this in early 26Q3 in order to evaluate if a EN code be
issued before 15.0 becomes EOL and fix the regressions.
Mediatek mt76 support
Work is ongoing to support multiple of the Mediatek mt76 drivers, foremost the
mt7921 and mt7925. After several of the LinuxKPI and LinuxKPI 802.11
improvements I can say that mt7921 passes packets with acceptable throughput
for the first cut. mt7925 does so equally but at least the outstanding LinuxKPI
IDR work leads to instabilities. mt7915 likewise needs needs IDR, but also
seems to not support hardware scan offloading, which means we do have to fix
software scanning for good, which will equally help rtw8x, which have the weird
software scan fallback in case hardware scan is not available. Further chipsets
will be tested once these land and are fully enabled in main.
In addition to the LinuxKPI works, we debugged one driver-triggered panic. It
turned out that the drivers would re-schedule some work during detach
(shutdown) but then free the underlying memory. This left a callout being
scheduled and once we tried to walk the callout list, we caused a panic.
LinuxKPI USB support
In Q1 we reported about a blocker for this. I am happy to announce that half of
the blocker got sorted, that is the compiler option I originally wanted to add
was now completely removed from the source tree in main and stable/15. LLVM by
now has a newer option which is only a subset of what the problematic original
allowed, which will be nice to move to in a year or two once a newer LLVM
release and GCC are shipping with it. This now leaves me with finding a
minimalistic solution to re-introduce it again, rather than spreading it over
the entire kernel or a gazillion of individual files. There is hope that it
will be sorted some time during 26Q3.
Native net80211 updates (tech debt)
• Some work last year discovered issues in the way we are presenting RSSI to
user space. Due to a possible double wraparound the values may not be
correct. The driver and net80211 parts of this problem were fixed. The user
space API is not fixed yet in order to avoid breakage (incl. major web
browsers).
• Talks have resumed during the last week of June in order to get ports fixed
using lib80211, which will help us to move forward on various issues
without constantly breaking user space.
Final note
It recently got quiet on issues despite more people using wireless on FreeBSD
again. I am not sure this is a good sign or not.
We appreciate all the feedback and problem reports we get and if they come in
on bugzilla we also try to categorize them into specific groups (see link).
Some may seem to fall through the cracks but we generally try not to let that
happen. Sometimes larger works are planned dedicated to the area of your
problem and so may not see immediate help, sometimes other things may be ahead
of the queue. If the issues are properly documented it will be easier to get
back to them at a later time. If you have any issues with (LinuxKPI based)
wireless please try to use the official channels: check open PRs, send a note
to the wireless mailing list, if needed drop me a private email (e.g., if you
have a core dump with possible private information), or open a new PR if the
issue is not yet known (or seems to fall through the cracks as then it is up
for public tracking).
Sponsor: The FreeBSD Foundation
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
DRM drivers
Links:
Update to Linux 6.13 DRM drivers URL:
https://github.com/freebsd/drm-kmod/pull/469
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, we finished the porting of DRM drivers from Linux 6.12 LTS in
time for the release of FreeBSD 15.1-RELEASE. Because this is an LTS version,
we will track changes from the Linux 6.12.x patches. Currently, we are at
6.12.81 and work is underway to continue to bump to the latest patch. These
drivers are available from the Ports tree and as packages.
As part of the work on 6.12 drivers, several bugs or regressions were fixed for
already supported GPUs. Some newer GPUs started to work as well.
We still have several instabilities to fix in both the i915 and the amdgpu
drivers.
We also continued to port DRM drivers from following Linux versions: * The
update to Linux 6.13 is under review and testing. * The update to Linux 6.14 is
ready as well and will be reviewed after the 6.13 update.
This work is kindly sponsored by the FreeBSD Foundation as part of the Laptop
and Desktop Project.
Sponsor: The FreeBSD Foundation
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
GENEVE Tunnel
Links:
Add Support for Geneve (RFC8926) URL: https://reviews.freebsd.org/D54172
Contact: Pouria Mousavizadeh Tehrani <pouria@FreeBSD.org>
Since the last report, I have committed the geneve(4) driver and it is now
available on CURRENT.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Series of IPv6 Improvements
Contact: Pouria Mousavizadeh Tehrani <pouria@FreeBSD.org>
For the past 6 months, I have worked on refreshing our IPv6 stack and
implementing pending RFCs in our stack, and they are now available on CURRENT.
So far, I have added the support for:
• RFC 9131 and RFC 9898 Section 3.9: Support for Gratuitous Neighbor
Discovery (GRAND).
• RFC 8781 (Section 5): Ability to have multiple PREF64 options.
• RFC 4861 (Section 7.2.6 - 7.2.8): Support for delayed Neighbor
Advertisement for both anycast and proxy addresses.
• RFC 4191: Support for Route Information option in Router Advertisement.
• Removed the support for DRAFT_IETF_6MAN_IPV6ONLY_FLAG to replace it with
RFC 8925.
Ongoing works:
• RFC 8925: IPv6-Only Preferred Option For DHCPv4 (D56637)
• RFC 4429: Add support for Optimistic DAD. (D55229)
I want to specially thanks Gleb Smirnoff for his timeless guidance and help on
these works.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Support for Routing Metric
Contact: Pouria Mousavizadeh Tehrani <pouria@FreeBSD.org>
I have been working on the metric implementation since 2026Q1. Routing metrics
are configuration values used by a router to make routing decisions. Router
metrics help the routing stack to choose the best route among multiple feasible
routes to a destination. The route will go in the direction of the gateway with
the lowest metric. Support for metric in our routing stack is implemented and
available in CURRENT. Metric support requires numerous updates to both kernel
and userland.
These are some highlights that were added:
• Support for metric in rtsock via rmx_metric.
• RTA_PRIORITY support for metric in netlink.
• The upper 8-bit weight reservation for metric has been removed.
• route(8) now shows the metric value.
• netstat(1) now shows the metric value of each route when -w is used.
You can also leverage metric using net/bird for your routing protocols.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Native MPLS Support for FreeBSD
Links:
GSoC Project Wiki
FreeBSD Source Fork
Contact: Subhash Murmu <subhashmurmujsr2511@gmail.com>
This project adds native Multiprotocol Label Switching (MPLS) support to the
FreeBSD kernel as part of Google Summer of Code 2026, mentored by Bruce Simpson
and Alexander Chernikov. MPLS is widely deployed for label-switched forwarding
in production networks, but FreeBSD has no MPLS data plane in the base system,
so MPLS-capable routing daemons have no kernel forwarding path to program. The
work is built bottom-up, from wire-level encapsulation through the control
plane, and integrates with the existing FreeBSD network stack rather than
sitting beside it.
Phases 1 through 3 are complete and pushed as a five-commit layered history on
the mpls branch of the Codeberg fork. Phase 1 adds link-layer encapsulation and
netisr(9) dispatch for EtherType 0x8847. Phase 2 ports OpenBSD’s ldpd(8) to
FreeBSD, where it now builds and runs. Phase 3 adds the forwarding engine and a
per-VNET Label Information Base, with end-to-end LSP transit verified under
tcpdump between VNET jails over epair(4).
The series has not yet been submitted to Phabricator. Work continues on kernel
route programming for ldpd.
Sponsor: Google Summer of Code 2026
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Bluetooth HID drivers
Links:
FreeBSD wiki project page URL:
https://wiki.freebsd.org/SummerOfCode2026Projects/BluetoothSupportForHIDDevices
Project GitHub repo URL: https://github.com/majintosh/freebsd-bthid
Contact: Majed Alkhaleefah <majed@FreeBSD.org>
I have been working on two drivers to enable support for HID drivers for
Bluetooth devices as part of GSoC 2026.
The primary goal of this project is to register connected Bluetooth HID devices
as Newbus devices via two new drivers: bthidbus and bthid. bthidbus acts as the
parent bus that manages the creation and attachment of bthid child devices.
bthid serves as the transport layer, spawning a hidbus device and routing all
received packets to it once they are stripped of their headers. The short-term
goal here is to enable support for wireless HID connections. The longer-term
goal is to begin setting the foundation that allows others to write drivers for
devices that can only connect via Bluetooth.
What has been accomplished:
• bthidbus can successfully open a connection to a Bluetooth device via
sockets.
• bthid can receive and manage sockets handed down from bthidbus via ivars.
• bthid can send the report descriptor to hidbus, which successfully spawns
the correct HID device and driver. (e.g., a gamepad connected over
Bluetooth spawns an hgame device and an evdev node.)
• Input from Bluetooth devices is successfully received by hidbus and evdev.
Current issues and planned changes:
• The actual report descriptors, Bluetooth addresses, etc, have to be
hardcoded into bthidbus. I initially considered adding the querying/
listening logic to bthidbus to make it act like a pseudo-server, but I
worried this would risk bloating and scope creep. The approach I will be
going with instead is to rely on the bthidd daemon’s existing querying
logic and have it send new connection information to bthidbus via an ioctl.
This would remove bthidbus 's current role as the connection-initiator and
instead have it only manage connections that have already been opened.
• There is significant input latency when monitoring via evtest. I have two
different working hypotheses. The first is that the issue lies in bthid and
how it manages interrupts via taskqueues. The second is that it lies in the
Networking stack, as Bluetooth packets are piped between multiple different
Netgraph nodes before being received by bthid. This could also very well be
an issue with evtest; I still have to look into this.
All testing so far has been done with the Nintendo Switch Pro Controller.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
NTSYNC(9)
Contact: Konstantin Belousov <kib@FreeBSD.org>
Recently there was a stream of articles hyping the Linux driver ntsync which
implemented a helper for Wine to accelerate Windows NT synchronization
primitives. The substrates to implement semaphores, mutexes, and events from
the Win32 land are provided by it. The driver represents each NT object as a
file descriptor, which has the set of the ioctls defined that directly map into
the Win32 operations.
The project implemented the driver providing the compatible ntsync interface as
specified in the Linux 7.0-rc3 document Documentation/userspace-api/ntsync.rst.
Both native FreeBSD interface, and the Linux ABI compatibility layers, are
written.
To test the driver, a minimal version of the Linux kernel test harness was
ported. FreeBSD driver follows the interface details as encoded by the tests,
when a discrepancy between Linux documentation and tests was found.
Both the driver and its man page ntsync(4) were written from scratch, without
consulting the Linux source code.
Sponsor: The FreeBSD Foundation
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Architectures
Updating platform-specific features and bringing in support for new hardware
platforms.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Raspberry Pi Imager FreeBSD Port
Links:
rpi-imager upstream URL: https://github.com/raspberrypi/rpi-imager
FreeBSD Port pull request URL:
https://github.com/raspberrypi/rpi-imager/pull/1655
PR 296480 - FreeBSD Ports open review URL:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=296480
Contact: Jim Chen <jim.chen.1827@gmail.com>
Contact: Nimish Jain <njain15@protonmail.com>
The Raspberry Pi Imager is a convenient graphical tool developed by the
Raspberry Pi Foundation that allows users to easily configure and flash
operating system images to storage cards for the Raspberry Pi Zero and
Raspberry Pi 1-5 series single-board computers.
Our goal in porting this app to FreeBSD is to continue lowering barriers to
entry. We want users unfamiliar with the command line to easily flash operating
systems to their Raspberry Pi.
Currently, the upstream project supports only Linux, MacOS, and Windows. We
have created a FreeBSD port that uses native I/O, disk, and network APIs and
links against pre-packaged FreeBSD libraries.
The main blocker for this project is currently upstream uncertainty. The
maintainers have requested buy-in from FreeBSD developers to help with the
long-term maintenance of the FreeBSD-specific code. If you are a committer or a
contributor invested in Raspberry Pi tooling on FreeBSD, please let us know or
join the discussion on the GitHub pull request!
If this work is accepted upstream, a Makefile for the FreeBSD Ports repository
is ready for review as PR 296480
(https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=296480).
If you’re interested, please do try out a local release by cloning the Ports
tree and applying the patch in the PR mentioned above, and let us know if you
have any issues!
Sponsor: The FreeBSD Foundation
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Enhancing Arduino and ESP32 Development Ecosystem on FreeBSD
Contact: Deepan Sai <skdeepan.sai@gmail.com>
Project Overview
I am working on adding the Arduino CLI package to the FreeBSD Ports Collection.
The Arduino CLI is a command line tool that helps users work with Arduino
boards. By adding it to FreeBSD I want to make it easier for developers to use.
Importance of the Work
A lot of people use Arduino CLI for embedded systems and automation. Having it
on FreeBSD as a port makes it easy to install and update the software. This
helps keep FreeBSD in line with tools that hardware and embedded developers
use.
Progress This Period
This time I worked on getting the new port ready to be reviewed. I wrote the
Makefile and made sure the package built correctly. I found a problem where a
test was failing because it did not have the settings for FreeBSD. I fixed
this. The test now works.
I did all the checks for a new port like making sure the files are in the right
place and that the tests run correctly. I also fixed some issues that people
found when they reviewed my work. The port is now much closer to being ready to
be added to the FreeBSD Ports Collection.
Sponsor: Google Summer of Code
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
FreeBSD Driver Development for BananaPi-R64/R2-PRO
Links:
Wiki URL: https://wiki.freebsd.org/arm/Bananapi
Contact: Martin Filla <freebsd@sysctl.cz>
Contributors are welcome. If you are interested in helping with this project,
testing the current implementation, or contributing code, please contact me.
R64 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 R64
Implemented so far:
• UART driver
• Clock management (clocks)
• Pinctrl
• Storage controllers (eMMC/SD/MMC) driver
• Ethernet Switch mt7531 driver
• Ethernet mt7622 driver
• XHCI driver
• Watchdog driver
• RTC driver
• RNG driver
• Pciecfg driver
• SysIRQ driver
• USB3
• T-PHY
Development roadmap R64
Implement missing drivers:
• SATA / AHCI
• Wi-Fi (likely MediaTek MT7615)
• GPIO subsystems
• I2C
• SPI
• PWM
• PCIE
R2-PRO Introduction
The Banana Pi BPI-R2 Pro is the next generation smart router development board.
It is powered by Rockchip RK 3568 processor. Onboard 2GB LPDDR4 memory and 16GB
eMMC storage, and supports 2 USB 3.0 interface, 5 gigabit network port. M.2
key-E and mini PCIe interface, 2 mipi DSI interface (one can change to LVDS by
software), 1 CSI camera interface, 1 HDMI output.
Current State of FreeBSD Support R2-PRO
Implemented so far:
• UART driver
• Clock management (clocks)
• Pinctrl
• GPIO
• Storage controllers (eMMC/SD/MMC) driver
• XHCI driver
• Watchdog driver
• PCIE driver
Development roadmap R2-PRO
Implement missing drivers:
• HDMI
• MIPI
• USB3
• SATA
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
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
Framework system management tools URL:
https://github.com/FrameworkComputer/framework-system
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: Sheng-Yi Hong <aokblast@FreeBSD.org>
Framework Computer Inc. continues to support the FreeBSD Project in many ways.
This includes providing engineering samples and development hardware to the
FreeBSD Foundation, helping with hardware testing, and working with FreeBSD
developers on compatibility improvements.
The Foundation continues to improve overall laptop support. Framework laptops
are among the target platforms of the Laptop Support and Usability Project.
During 2026Q2, Daniel updated the sysutils/framework-system port to version
0.6.2 and later to version 0.6.4. This package provides Framework-specific
system and firmware management tools for FreeBSD users.
Framework also hosted a small hackathon at its Taipei office during the
quarter. FreeBSD developers tested newly announced hardware, including the
Intel Panther Lake-based Framework Laptop 13 Pro and the 10GbE adapter.
Li-Wen is working on FreeBSD support for the 10GbE adapter, which uses a
Realtek RTL8159 controller.
Support for Intel Panther Lake systems also progressed through development and
testing on Framework hardware, including pre-release systems made available by
Framework during the Taipei hackathon. Daniel added PCI IDs for Panther Lake
I2C and SMBus controllers, and Sheng-Yi committed the work to FreeBSD. A
follow-up correction removed an ID for an SPI flash controller that had been
incorrectly identified as an SPI bus controller.
In June, Li-Wen also started testing and debugging the Linux 6.12-based DRM
drivers from the graphics/drm-612-kmod port, which was added during the quarter
. He investigated display-related problems on Framework systems and suspected
that some of them might be the same as, or related to, the external-display
hot-plug problem tracked in the Laptop Support and Usability Project. The
investigation was still in progress at the end of the quarter and continued
into Q3.
Power and performance management continued to improve on both Intel and AMD
systems. Framework systems were among the development and test platforms used
for this work. Some systems were provided by Framework, while FreeBSD
developers also carried out development and testing on their own Framework
hardware.
Sheng-Yi disabled Intel HWP package-control mode on hybrid-core CPUs. Without
this change, a request from an efficiency core could limit all cores to its
performance level and cause a significant loss of performance.
Other HWP and CPPC improvements completed during the quarter include:
• Exposing available AMD legacy-pstate nodes.
• Caching AMD CPUID information.
• Using IPIs for Intel per-CPU HWP updates.
• Using the full 8-bit Intel Energy Performance Preference scale.
Work also progressed on suspend and resume support for the Framework Laptop 12.
Devin Teske developed and tested a proposed ACPI fix for a wake-up issue that
could cause the system to suspend again immediately after resume. Daniel
investigated the laptop’s ACPI and embedded-controller firmware behavior, while
Warner Losh and Olivier Certner provided technical review and helped improve
the implementation.
Sponsor: The FreeBSD Foundation for Li-Wen and Sheng-Yi’s work
Sponsor: Framework Computer Inc. for Daniel’s work and for hardware and space
provided to the project
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
ROCm support on FreeBSD
Links:
drm-kmod fork with partial amdkfd support URL:
https://github.com/Yohello1/drm-kmod-rocm/tree/super-special
rocm-systems fork with fixes for FreeBSD URL: github.com/Yohello1/rocm-systems
Contact: Sourojeet Adhikari <siri@racha.ca>
ROCm is the compute platform used by AMD for their GPUs. As of now, FreeBSD
does not support ROCm at all, neither at the toolchain level nor at the driver
level. I am working to change that and upstream the required changes.
To my knowledge, on FreeBSD there are a few ways to run compute loads (like AI/
ML, graphics, etc) on the GPU; those ways, to my knowledge, are Vulkan and
OpenGL. Both Vulkan and OpenGL are fairly good for compute workloads, namely in
graphics and sometimes machine learning loads too. But sometimes there are
tasks which are not well-suited for Vulkan and OpenGL, and are instead done in
ROCm/CUDA because ROCm and CUDA give the developer a lot more control over how
the task is done. So I am trying to introduce ROCm support to FreeBSD so we can
run ROCm code/programs on FreeBSD. There are a few things we need working to
get ROCm working. The first is AMD’s LLVM fork, which I have patched, gotten
working, and have upstreamed the patches. Next are the ROCm runtimes, which
have been patched, and I am currently working on upstreaming the patches.
Finally is the amdkfd driver, which I am working on patching, and am
upstreaming some of the LinuxKPI-related patches back to the FreeBSD kernel.
As of late, I have upstreamed changes to AMD’s LLVM fork allowing the
compilation of their fork on FreeBSD so you can build their ROCm toolchain.
Beyond that, I have worked on getting a series of patches into LinuxKPI to
slowly bring in amdkfd support.
Sponsor: The FreeBSD Foundation
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Cloud
Updating cloud-specific features and bringing in support for new cloud
platforms.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
FreeBSD on EC2
Contact: Colin Percival <cperciva@FreeBSD.org>
FreeBSD is available on both amd64 (Intel and AMD) and arm64 (Graviton) EC2
instances.
An issue causing the ena(4) driver to drop packets when receiving jumbograms
has been fixed. The fix was present in 15.1-RELEASE (June) and will be present
in 14.5-RELEASE (September). This fix improved single-TCP-stream network
performance on some EC2 instances from 110 Mbps to 9.5 Gbps and also
significantly improved multiple-TCP-stream throughput.
An issue causing the ena(4) driver to launch taskqueues on the wrong CPU(s) on
NUMA systems has been identified. The fix should be present in 14.5-RELEASE
(September) and produces a 2x increase in multiple-TCP-stream throughput on
c8gn.48xlarge instances.
Sponsor: Amazon
Sponsor: https://www.patreon.com/cperciva
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
FreeBSD on Microsoft HyperV and Azure
Links:
Microsoft Azure article on FreeBSD wiki URL:
https://wiki.freebsd.org/MicrosoftAzure
Microsoft HyperV article on FreeBSD wiki URL: https://wiki.freebsd.org/HyperV
Contact: Microsoft FreeBSD Integration Services Team <bsdic@microsoft.com>
Contact: freebsd-cloud Mailing List
Contact: The FreeBSD Azure Release Engineering Team <releng-azure@FreeBSD.org>
Contact: Wei Hu <whu@FreeBSD.org>, <weh@microsoft.com>
Contact: Li-Wen Hsu <lwhsu@FreeBSD.org>
Publishing the 15.1-RELEASE image to Azure Marketplace is in progress. It is
expected to become publicly available early in the third quarter.
Li-Wen is investigating the technical details needed to support Azure Trusted
Launch.
Wei and Li-Wen, together with other Microsoft engineers, are investigating an
issue preventing mana(4) from working correctly on AMD-based Azure VMs. The
mana(4) device is present on the latest v7-generation Azure VMs.
Work in progress tasks:
• Automating the image publishing process and merging it into src/release/.
• Making the process of publishing to Azure Marketplace smoother.
• Supporting FreeBSD in Azure VM utilities.
Open tasks:
• Update FreeBSD-related documentation at Microsoft Learn.
• Update sysutils/azure-agent to the latest version.
• Upstream local modifications of Azure agent.
• Port Linux Virtual Machine Extensions for Azure.
• Add FreeBSD support in Azure Pipelines.
□ https://github.com/microsoft/azure-pipelines-agent/pull/3266
□ Build and publish snapshot builds to Azure community gallery.
Sponsor: Microsoft for people in Microsoft, and for resources for the rest
Sponsor: The FreeBSD Foundation for everything else
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Documentation
Noteworthy changes in the documentation tree, manual pages, or new external
books/documents.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
The FreeBSD Russian Documentation Project
Links:
The FreeBSD Official Website in Russian URL: https://www.freebsd.org/ru/
FAQ URL: https://docs.freebsd.org/ru/books/faq/
The FreeBSD Russian Documentation Project site URL:
https://github.com/freebsd-doc-ru/freebsd-doc/discussions
Contact: Andrey Zakhvatov <andy@FreeBSD.org>
Contact: Vladlen Popolitov <vladlen@FreeBSD.org>
The FreeBSD Russian Documentation Project’s current goal is to provide
up-to-date Russian translations of the most important parts of the FreeBSD
documentation (FAQ, Handbook, website content). It is essential to support
Russian-speaking users with high-quality official technical materials and to
increase the adoption of the operating system worldwide. We hope this
initiative will gain support within the Russian-speaking FreeBSD community and
lead to an increase in translated materials.
During the last quarter:
• 100% of the text in Weblate has been translated.
• The Russian language section of www.FreeBSD.org/ru has been fully
translated, with 100% of its pages now available in Russian.
• For the FreeBSD 15.1 release, the complete set of release documentation
(release notes, errata, etc.) has been translated into Russian in a timely
manner alongside the English originals.
• The project to translate FreeBSD man pages has been initiated and is in its
very early stages. Preliminary examples can be found at GitHub.
Plan for the next quarter:
• Continue the ongoing efforts to translate FreeBSD man pages.
Check the official translation guide if you would like to help.
We would appreciate your assistance with translating the following materials:
• Web pages
• Man pages
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Ports
Changes affecting the Ports Collection, whether sweeping changes that touch
most of the tree, or individual ports themselves.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Dockerbox
Links:
freebsd-dockerbox GitHub URL: https://github.com/leafoliage/freebsd-dockerbox
dockerbox-broker GitHub URL: https://github.com/leafoliage/dockerbox-broker
freebsd-dockerbox-debian GitHub URL:
https://github.com/leafoliage/freebsd-dockerbox-debian
Contact: Chun-Cheng Yeh <leafoliage@FreeBSD.org>
Dockerbox is a virtualized Docker daemon. Although the Docker daemon is not
natively available on FreeBSD, Dockerbox runs it inside a Debian Bhyve virtual
machine to provide access to it. Dockerbox supports common Docker features such
as Docker Compose, port publishing, and bind mounts. This project aims to
facilitate non-production Docker usage on FreeBSD.
Related Ports and Repositories
• freebsd-dockerbox
Provides Docker on FreeBSD by running dockerd inside a Linux Bhyve VM. This
service manages the lifecycle of the Dockerbox guest, along with its
network and storage settings.
v0.2.5 — ported.
• dockerbox-broker
A child service of Dockerbox that handles port forwarding from the host to
the Dockerbox guest when a container requests port publishing.
Not yet ported.
• freebsd-dockerbox-debian
Codebase used to generate Dockerbox’s disk image.
Not ported.
• docker-cli
The Docker CLI tool.
v29.4.2 — ported.
• docker-compose
A Docker CLI plugin for defining and running multi-container applications.
v5.1.3 — ported.
• docker-buildx
A Docker CLI plugin providing extended build capabilities via BuildKit.
v0.34.1 — ported.
sysutils/dockerbox, sysutlis/docker-cli, sysutils/docker-compose, and sysutils/
docker-buildx are now available in the FreeBSD Ports Collection and via pkg.
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.
Infrastructure
CMake was updated to 3.31.12.
Qt6 and PySide6 were updated to 6.11.1. PyQt6 was updated to 6.11.0.
Qt5 and PySide2 were updated to 5.15.19 KDE patch collection. Upstream standard
support for Qt5 is officially over. This is the final update for Qt5.
KDE Stack
KDE Frameworks, Plasma, and Gear release happen very regularly. KDE team lands
these updates shortly after their upstream release.
• KDE Frameworks ports were updated to 6.28.0.
• KDE Plasma Desktop was updated to 6.6.6.
• KDE Gear was updated to 26.04.3.
Related Ports
A number of new KDE ports have been added. Amarok, the classic KDE music
player, has been reinstated and updated to 3.3.3.
Sunsetting Qt5 ports
Qt5 is still used by approximately 350 ports. Although Qt5 is deprecated there
is no definite date for its removal from the ports tree yet. Still, the port
for Qt5WebEngine which is based on very old Chromium with multiple
vulnerabilities is scheduled for removal just before 2026Q4. KDE team
encourages maintainers to migrate their ports to Qt6, remove Qt5 flavors, and
remove abandoned Qt5 software.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
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/
GCC 17 release series URL: https://gcc.gnu.org/gcc-17/
Contact: Lorenzo Salvadore <salvadore@FreeBSD.org>
Two new ports have been created: lang/gcc16 and lang/gcc17-devel.
PR 294062 about arm64 build failures has been fixed. More precisely, in 2026Q2
lang/gcc16-devel and lang/gcc17-devel have been fixed, while lang/gcc16 has
been fixed in the beginning of 2026Q3 (at the time this report is written the
patch still needs to be forwarded to the ports quarterly branch).
Unfortunately, the solution is local to the FreeBSD ports tree and cannot be
upstreamed directly. Discussion for an upstream solution can be found in the
upstream bugzilla. Thanks to all those who have helped, in particular to Mark
Millard.
I have not worked personally on the process to get GCC_DEFAULT=15 this quarter,
but some work is being done in the associated PRs, so this is getting forward
as well. Moreover, minor version updates to lang/gcc13, lang/gcc14 and lang/
gcc15 are planned.
As I continue to work on the GCC ports, I realize that I am having less time
and less energy to put into them. These ports are important, I prefer not to
leave them unmaintained at least until I am able to deal with them, even if
slowly. But if there is someone who would like to take them, please stand up
and I would be glad to transfer maintainership.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Improve OpenJDK on FreeBSD
Links:
Project description URL:
https://freebsdfoundation.org/project/improving-openjdk-on-freebsd/
Project repository URL: https://github.com/freebsd/openjdk
Upstream BSD port repo URL: https://github.com/openjdk/bsd-port
Contact:
Harald Eilertsen <haraldei@FreeBSD.org>
FreeBSD Java mailing list <freebsd-java@lists.freebsd.org>
The goal of this project is to improve OpenJDK support for FreeBSD/amd64 and
FreeBSD/arm64.
Java is an important runtime environment for many high performance, critical
enterprise systems. Making sure Java based applications run correctly and
efficiently on FreeBSD is important to ensure that FreeBSD will continue to be
a viable and attractive platform for enterprises, as well as businesses and
organizations of all sizes.
This quarter has been spent mostly on getting the upstreaming process properly
going. We submit patches to a separate repository under the OpenJDK org on
GitHub, and make sure that each PR is reviewed by at least one upstream
reviewer. This way, when we get to the point where we want to merge our port
into the upstream mainline, all commits should already be reviewed by someone
in the project.
This is a fairly slow process, as we depend on upstream reviewers having time.
We also encounter that some of the changes that has been living in our port for
a long time is rejected. Then we have to rework them, or if not strictly
needed, just throw them out. I feel this is a useful correction, but sometimes
causes quite a bit of work.
In this quarter the following issues/milestones were reached:
• OpenJDK 25 port was updated to version 25.0.3.
• Upstream mainline changes and bugfixes:
□ 8382614: Consolidate implementation of current_stack_base_and_size on
BSD
□ 8384085: Make os::Bsd::dlopen_helper private, and drop unused arg
□ 8384088: osThread _thread_id should be an int on all BSD’s
□ 8384946: os::Bsd::gettid misses the return value
□ 8386344: runtime/StackGuardPages/TestStackGuardPages build failure
after JDK-8303612
• Upstream BSD Port:
□ Fix conditional sections for BSD in hotspot/cpu
□ Port hotspot/os/posix for BSD
□ Merged changes accepted for mainline.
• Current (out-of-tree) BSD port:
□ Merge + Remove VFORK for BSD + rebase GHA workflow on OpenJDK26
□ Merge + Fix usage of FREE_C_HEAP_ARRAY macro on BSD
□ Sync aarch64 cpuinfo impl for *BSD with Linux
□ Remove duplicate include in global defs for zero
□ Remove ThreadWXEnable from BSD code
□ Backported changes accepted for mainline upstream BSD port.
• Ports:
□ java/javavmwrapper: JAVA_VERSION does not work with openjdk25
In addition, these tasks are still ongoing, or waiting for review:
• Upstream BSD port:
□ Port hotspot/os/bsd/os_perf_bsd.cpp to BSD (Waiting for refactor, see
WIP: Split os_perf impl for macOS and BSD)
□ os::get_process_uid and os::rss for BSD (Still ongoing)
Other notes:
• Started preparing for OpenJDK 27 port.
• Presented the project at Foss North 2026.
Sponsor: The FreeBSD Foundation
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
FreeBSD HPC Ports Modernization: Slurm 26.05, UCX 1.20 Upstreaming, and
MPI-Parallel File Utilities
Links:
sysutils/slurm-wlm URL: https://cgit.freebsd.org/ports/tree/sysutils/slurm-wlm/
net/ucx URL: https://cgit.freebsd.org/ports/tree/net/ucx/
sysutils/mpifileutils URL: https://cgit.freebsd.org/ports/tree/sysutils/
mpifileutils/
devel/libcircle URL: https://cgit.freebsd.org/ports/tree/devel/libcircle/
devel/lwgrp URL: https://cgit.freebsd.org/ports/tree/devel/lwgrp/
devel/dtcmp URL: https://cgit.freebsd.org/ports/tree/devel/dtcmp/
benchmarks/py-reframe-hpc URL:
https://cgit.freebsd.org/ports/tree/benchmarks/py-reframe-hpc/
openucx/ucx#11354: UCS/TYPE portability fixes for non-glibc/Clang environments
(merged) URL: https://github.com/openucx/ucx/pull/11354
openucx/ucx#11549: UCS/SYS portability fixes for non-Linux platforms (in
review) URL: https://github.com/openucx/ucx/pull/11549
hpc/mpifileutils#664: Portability fixes for FreeBSD/non-Linux builds (in
review) URL: https://github.com/hpc/mpifileutils/pull/664
Kavocado Monthly Status Reports – FreeBSD HPC notes
URL: https://kavocado.net/reports/
Contact: Generic Rikka <rikka.goering@outlook.de>
This report continues the FreeBSD HPC Ports Modernization initiative. Previous
quarters focused on bringing the Slurm + PMIx + PRRTE + UCX stack up to date
and filling gaps in the surrounding ecosystem. This quarter’s work centered on
three things: keeping the core scheduler and communication libraries current
against fast-moving upstream releases, upstreaming the FreeBSD portability
fixes accumulated while maintaining these ports so the local patchsets keep
shrinking, and adding a new port for MPI-parallel file utilities that are
common on large HPC filesystems.
Work completed
• Updated sysutils/slurm-wlm twice this quarter, from 25.11.4 to 25.11.5 and
then from 25.11.5 to 26.05.1, tracking the latest upstream releases.
• Fixed several FreeBSD-specific runtime issues in net/ucx: hardened async
thread state handling, corrected UCM relocation handling, fixed mm signal
socket binding, and resolved other FreeBSD runtime portability issues.
• Updated net/ucx from 1.20.0 to 1.20.1, and separately fixed a libucm
early-init panic together with several gtest suite failures uncovered while
validating the update.
• Added sysutils/mpifileutils as a new port, along with its dependency stack:
devel/libcircle, devel/lwgrp, and devel/dtcmp. These provide MPI-parallel
file utilities (copy, remove, checksum, etc.) commonly used on large HPC
filesystems.
• Updated benchmarks/py-reframe-hpc twice this quarter to track upstream
releases of the regression testing framework.
• Upstreamed "UCS/TYPE: Portability fixes for non-glibc/Clang environments"
to UCX, which was reviewed and merged.
• Opened "UCS/SYS: portability fixes for non-Linux platforms" against UCX,
covering hostname buffer sizing, MAC address retrieval via getifaddrs()/
AF_LINK, shared-memory error reporting, mmap/munmap-based reallocation, and
cpuset_getaffinity()-based thread affinity queries; currently addressing
review feedback.
• Opened a portability PR against mpifileutils guarding Linux-only APIs for
FreeBSD and other non-Linux builds; currently in review.
• Collaborated with SchedMD on a Slurm configure-time probe for H5PTopen,
used to detect the HDF5 high-level library, which was merged upstream.
Work in progress
• Addressing reviewer feedback on the open UCX and mpifileutils portability
pull requests to get them merged upstream and reduce the FreeBSD ports'
local patchsets further.
• Continuing collaboration with SchedMD to upstream additional portability
fixes discovered while maintaining sysutils/slurm-wlm on FreeBSD, including
BSD socket-handling improvements.
• Evaluating a proctrack/freebsd_reaper Slurm plugin design, made possible by
recently landed FreeBSD kernel support for exposing reaper metadata in
process information.
• Continuing to track upstream Slurm, UCX, and PMIx/PRRTE releases closely to
keep the FreeBSD ports current with minimal local patching.
Future plans
• Land the outstanding UCX and mpifileutils upstream pull requests, and
continue identifying further portability issues to upstream rather than
patch locally.
• Prototype and submit the Slurm proctrack/freebsd_reaper plugin once the
underlying kernel interface work is finalized.
• Continue expanding the HPC software ecosystem available in the FreeBSD
Ports Collection and reduce local patchsets across the stack wherever
upstream acceptance is possible.
• Document a reference Slurm + OpenMPI + PMIx + PRRTE + UCX deployment on
FreeBSD to lower the barrier for new sites experimenting with FreeBSD in an
HPC context.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Improve libvirt support for bhyve hypervisor
Links:
libvirt: Bhyve driver URL: https://libvirt.org/drvbhyve.html
Contact: Roman Bogorodskiy <novel@FreeBSD.org>
Completed work
• libvirt/bhyve driver:
□ virtio-console device support added.
□ QEMU Guest Agent support added.
□ Implemented a few features based on the QEMU Guest Agent, such as
graceful reboot and shutdown, managing guest OS time, SSH keys, users
passwords, etc.
□ Added memory tuning and block I/O tuning based on rctl(8).
• Work in progress on extend libvirt CI to test against FreeBSD-CURRENT
snapshot VM images.
Plans for the next quarter
• Add support for boot order configuration.
• Add support for TPM devices.
• Complete suspend/resume support.
• Continue implementing features based on the QEMU Guest Agent.
• Continue extending CI, cover the new guest agent based features with new
tests.
Sponsor: The FreeBSD Foundation
home |
help