[continued from previous message]

using the SFTP protocol by default. The -O flag is available to use the previous protocol instead.

Sponsor: The FreeBSD Foundation

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

pf status update

Contact: Kristof Provost <kp@FreeBSD.org> Contact: Reid Linnemann < rlinnemann@netgate.com>

Ethernet

pf recently grew support for filtering on Ethernet layer. See the 2021q2 pf_ethernet report.

Since then the Ethernet layer filtering has been extended with:

• anchor support

• ability to look into the layer 3 header, for matching with source/
destination IP(v4/v6) addresses

• table support for IP address matching

• direct dispatch to dummynet

• pass Ethernet layer packets directly to dummynet, rather than tagging the
packets and relying on layer 3 to handle dummynet

Dummynet

pf recently started being able to use dummynet for packet scheduling. This support has been extended and improved, and is now believed to be ready for production.

One notable fix is that reply-to/route-to’d traffic is now subject to dummynet
scheduling as well.

Last match timestamp

pf now tracks when a rule was last matched. Similar to ipfw rule timestamps, these timestamps internally are uint32_t snaps of the system "wall time" clock in seconds. (See time(9).) The timestamp is CPU local and updated each time a rule or a state is matched.

Sponsor: Rubicon Communications, LLC ("Netgate")

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Kernel

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

ENA FreeBSD Driver Update

Links:
ENA README URL: https://github.com/amzn/amzn-drivers/blob/master/kernel/fbsd/ ena/README.rst

Contact: Michal Krawczyk <mk@semihalf.com>
Contact: Dawid Gorecki <dgr@semihalf.com>
Contact: Marcin Wojtas <mw@FreeBSD.org>

ENA (Elastic Network Adapter) is the smart NIC available in the virtualized environment of Amazon Web Services (AWS). The ENA driver supports multiple transmit and receive queues and can handle up to 100 Gb/s of network traffic, depending on the instance type on which it is used.

Completed since the last update:

• Upstream of the ENA driver v2.5.0, which included:

• Improvement to the reset routine handling,

• Extension of the timer service lifetime in order to be able to detect more
hardware failures,

• Fix logic for verifying the Tx request ID,

• Fix IPv6 L4 checksum offload handling for the Tx,

• Add NUMA awareness to the driver.

• Internal review of the upcoming ENA driver release (v2.6.0), including:

• Further reset handling improvements,

• Code cleanup and style fixes,

• Logging improvements,

• Fix to the retrieval of the ENI metrics.

Work in progress:

• Testing of the upcoming ENA driver release (v2.6.0).

Sponsor: Amazon.com Inc

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

New Bluetooth® configuration daemon: blued

Links:
blued git URL: https://git.lysator.liu.se/kempe/blued

Contact:
Mail: kempe@lysator.liu.se
IRC: kempe@libera.chat

Introduction

The blued utility provides an IPC interface that lets an unprivileged user connect to and use Bluetooth devices in a user-friendly way and supports secure simple pairing (public-key cryptography and if the device allows it man-in-the-middle protection).

What is blued?

There are three parts to blued: a library, a daemon and a command line utility. The library abstracts away bluetooth details, the daemon manages Bluetooth devices and the command line utility lets users list or scan for Bluetooth devices, pair with a device, or unpair from one. The command line utility communicates with the daemon via a UNIX socket.

Unlike bthidd and hcsecd, blued supports secure simple pairing and provides an IPC. To get a HID device to work, bthidd is still needed. A script is provided to pair a Bluetooth device and appropriately configure bthidd so it just works and reconnects without user intervention.

Once pairing has proven stable and bugs have been ironed out, the plan is to integrate bthidd with/into blued in some way to have HID devices automatically start functioning when paired without the use of an external script. A long-term goal is to provide a graphical user interface that can list devices and provide a simple one-click setup to connect them.

Installing and using blued v0.1

You need the optional src component installed in /etc/src.

First, make sure you have working Bluetooth drivers loaded as explained in the FreeBSD handbook.

To test blued, fetch the blued v0.1 source code. Then compile it, patch your FreeBSD kernel with the patches in kernel_patches, and recompile the hci module as explained in README.

I have primarily tested blued on FreeBSD 12.3, but my patches applied cleanly on 13.1 when I tested. I am not supplying a port at the moment, but it is possible to run the software straight from the build directory or run "make install" that will install all needed files. Both blued and bluecontrol use capsicum and blued can be configured to drop its root privileges.

For more information, refer to the Running blued section of README.

Helping out

Testing

I have only tried this software with my own mouse and realise that a sample size of one single bluetooth device is pretty small. I’m expecting issues and am greatly looking forward to feedback from others!

In case of trouble, output from /var/log/debug.log and /var/log/messages as well as a traffic dump from "hcidump -x" while trying to pair will help with troubleshooting.

Contributing

If you want to get involved with the code and submit patches, you’re welcome to
visit the repository on Lysator’s Git.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

OpenVPN DCO

Links:
D34340 URL: D34340
OpenVPN wiki URL: OpenVPN wiki

Contact: Kristof Provost <kp@FreeBSD.org>

OpenVPN DCO (or Data Channel Offload) moves OpenVPN data packet processing into the kernel.

Traditionally OpenVPN uses a tun(4) interface to transmit and receive packets. In this setup received packets are received by the kernel, passed to the OpenVPN application for decryption, then passed back into the kernel for network stack processing. This requires several transitions between kernel- and userspace, and naturally imposes a performance cost.

The new if_ovpn OpenVPN DCO offload driver performs the encryption/decryption entirely within the kernel, improving performance.

Initial performance testing shows throughput improved from around 660Mbit/s to around 2Gbit/s.

The userspace OpenVPN code also requires modification to use the new if_ovpn offload driver. This is expected to be part of a future 2.6.0 OpenVPN release.

Sponsor: Rubicon Communications, LLC ("Netgate")

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Wireless updates

Links:
Intel iwlwifi status FreeBSD wiki page URL: https://wiki.freebsd.org/WiFi/ Iwlwifi Realtek rtw88 status FreeBSD wiki page URL: https://wiki.freebsd.org/ WiFi/Rtw88 Realtek rtw89 status FreeBSD wiki page URL: https://wiki.freebsd.org /WiFi/Rtw89

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

The overall project aims to bring support for newer chipsets to FreeBSD currently using LinuxKPI compat code backed by native net80211 and kernel code. In addition the aim is to continue work towards supporting newer wireless standards. During the second quarter 40 commits went into FreeBSD CURRENT. With more users trying multiple drivers support time has also gone up.

An earlier version of the Intel iwlwifi-derived wireless driver shipped in 13.1-RELEASE bringing this work into a first FreeBSD release. The iwlwifi driver and firmware were since updated in CURRENT and stable/13 again as part of ongoing development. Changes in files shared with the upstream Intel Linux version of the driver are now less than 400 lines. Lately a longer-standing problem for older chipsets was (hopefully) solved allowing iwm(4)-supported cards to work with iwlwifi(4) again after almost three months. The main focus for the project until the end of the year will most exclusively be getting us to contemporary speeds.

On April 1st, using the same LinuxKPI infrastructure built mostly with the iwlwifi work, Realtek’s rtw88(4) driver got comitted into CURRENT. Due to an issue with DMA the next weeks a workaround was developed and put into the tree so users no longer have to patch the kernel. The driver still needs a tunable set in loader.conf for machines with more than 4GB of physical memory. This tunable allowed the driver to be merged to stable/13 in June followed by further updates in CURRENT and stable/13. As the USB parts for rtw88 based chipsets are prepared to be included in Linux, work has started (needing more time) to prepare FreeBSD to be able to support the USB parts as well.

During the last months Realtek’s rtw89 has already been compiling and remains a
work in progress to run stably and associate before it can be enabled in CURRENT.

Thanks to all the users for testing and reporting back, patiently waiting for the next update, bugfix, or just a reply from me. It is a great pleasure to work with you! Keep sending the bug reports to me, but remember that your thanks should go to the FreeBSD Foundation for making most of this possible.

For the latest state of the development, please follow the freebsd-wireless mailing list and check the wiki pages.

Sponsor: The FreeBSD Foundation

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Shared page address randomization

Links:
D35392 D35393 D35349

Contact: Kornel Duleba <mindal@semihalf.com>
Contact: Marcin Wojtas <mw@FreeBSD.org>

The shared page is an R/X page that is mapped into each process by the image activator. It stores the signal trampoline, as well as other metadata e.g. information needed to implement user space timecounters. Previously it was mapped at the top of the process virtual address space. With the described changes its address will be randomized. We plan to turn the feature on by default for 64bit binaries, across all architectures. Currently the patches are under review and await approval.

Sponsor: Stormshield

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Architectures

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

NXP DPAA2 support

Links
Change history
Tree

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

Some of the NXP SoCs (LX2160A, LS1088A) are shipped with DPAA2, the second generation of the data path acceleration architecture. It allows to dynamically configure and wire packet processing "objects" (DPNI for a network interface, DPMAC for media access controller, etc.) together to form a network-on-a-chip.

During the last quarter the driver started working well enough to be used on SolidRun' Honeycomb LX2 (ACPI test platform) and Traverse Technologies has produced a FreeBSD preview for (their) Ten64 (used as FDT test platform).

The driver is still work-in-progress, but is getting close for a review to get the first version into the tree for everyone to benefit from it.

WIP:

• FDT MDIO support. FreeBSD currently lacks support for the SPF parts.

• Driver resources de-allocation to unload dpaa2.ko properly.

• Bug fixes and improvements.

TODO:

• CPU affinity for DPIOs and DPNIs.

• Cached memory-backed software portals.

• Bottlenecks mitigation.

• Further parts (DPSW, DCE, etc.) supported by the hardware.

Sponsor: Bare Enthusiasm :)
Sponsor: Traverse Technologies (providing Ten64 HW for testing)

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Medium-sized superpages on arm64 and beyond

Contact: Eliot H. Solomon <ehs3@rice.edu>
Contact: Alan L. Cox <alc@rice.edu>

The 64-bit ARM architecture’s page table descriptor format contains a flag called the Contiguous bit. This tells the MMU that it can cache an aligned, physically contiguous group of 16 page table entries which have identical permissions and attributes using only 1 TLB entry.

The Contiguous bit, as well as the conceptually similar Svnapot extension to the RISC-V architecture, allows for the use of 64 KiB superpages. These medium-sized superpages can bring to smaller memory objects the address-translation speedup typically associated with more traditional 2 MiB superpages.

This project focuses on bringing support for medium-sized superpages to FreeBSD. So far, we have modified the arm64 pmap code to automatically utilize 64 KiB superpages by detecting physically contiguous page table entries and promoting them using the Contiguous bit. Now, we are working to adapt the kernel’s superpage reservation module to support 64 KiB reservations in addition to the current 2 MiB ones. Adding medium-sized reservations will allow the virtual memory system to explicitly allocate pieces of memory which fit the requirements for superpage promotion, rather than just hoping that they occur by chance.

Our goal is to accomplish this in a general way that makes it possible to specify multiple arbitrary power-of-two reservation sizes, making it easier to take advantage of hardware features on other architectures like Ryzen’s PTE Coalescing, which transparently merges groups of 4 KiB page table entries into medium-sized superpages.

Sponsor: Department of Computer Science, Rice University

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Documentation

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

Documentation Engineering Team

Link: FreeBSD Documentation Project
Link: FreeBSD Documentation Project Primer for New Contributors
Link: Documentation Engineering Team

Contact: FreeBSD Doceng Team <doceng@FreeBSD.org>

The doceng@ team is a body to handle some of the meta-project issues associated with the FreeBSD Documentation Project; for more information, see FreeBSD Doceng Team Charter.

During the last quarter, Graham Perrin (grahamperrin@) and Pau Amma (pauamma@), were granted documentation commit bits.

Several items are pending and in discussion:

• Mirroring the Website and Documentation portal with the GeoDNS
infrastructure of the project.

• How to handle Trademarks in the documentation.

• Remove outdated translations from the Website and Documentation portal.

FreeBSD Translations on Weblate

Link: Translate FreeBSD on Weblate
Link: FreeBSD Weblate Instance

Q2 2022 Status

• 12 languages

• 152 registered users (9 new users)

Languages

• Chinese (Simplified) (zh-cn)

• Chinese (Traditional) (zh-tw)

• Dutch (nl)

• French (fr)

• German (de)

• Indonesian (id)

• Italian (it)

• Norwegian (nb-no)

• Persian (fa-ir)

• Portuguese (pt-br)

• Spanish (es)

• Turkish (tr)

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.

FreeBSD Website Revamp - WebApps working group

Contact: Sergio Carlavilla <carlavilla@FreeBSD.org>

Working group in charge of creating the new FreeBSD Documentation Portal and redesigning the FreeBSD main website and its components. FreeBSD developers can follow and join the working group on the FreeBSD Slack channel #wg-www21. The work will be divided into four phases:

1. Redesign of the Documentation Portal

Create a new design, responsive and with global search. (Complete)

2. Redesign of the Manual Pages on web

Scripts to generate the HTML pages using mandoc. (Work in progress)

3. Redesign of the Ports page on web

Ports scripts to create an applications portal. (Work in progress)

4. Redesign of the FreeBSD main website

New design, responsive and dark theme. (Not started)

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Ports

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

KDE on FreeBSD

Links:
KDE FreeBSD URL: https://freebsd.kde.org/
KDE Community FreeBSD URL: https://community.kde.org/FreeBSD

Contact: Adriaan de Groot <kde@FreeBSD.org>

The KDE on FreeBSD project packages the software from the KDE Community, along with dependencies and related software, 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 (kde@) is part of desktop@ and x11@ as well, building the software stack to make FreeBSD beautiful and usable as a daily-driver graphics-based desktop machine. The notes below describe mostly ports for KDE, but also include items of import to the entire desktop stack.

KDE Stack

KDE Gear releases happen each quarter, KDE Plasma updates once a month, and KDE Frameworks have a new release each month as well. These (large) updates land shortly after their upstream release and are not listed separately.

• astro/kstars latest release 3.5.9.

• deskutils/grantleetheme got an entry in UPDATING because of some unusual
changes to the installed structure of the port.

• deskutils/kalendar joined the KDE Gear releases.

• devel/okteta updates to the binary (and octal and hexadecimal) data viewer
and editor.

• finance/kraft needed specific build-fixes for newer KDE Frameworks.

• games/gcompris-qt expanded, new releases, and now supports more image
formats (needed for some activities).

• graphics/digikam no longer needs a SQL server during the build.

• graphics/krita was updated to 5.0.5, likely the last 5.0 version.

• math/labplot has a huge number of new features in recent releases, well
worth looking at if you need any kind of data-plotting.

• net-im/ruqola was updated. This is a Qt-styled Rocket chat application.

• www/falkon joined the KDE Gear releases.

Related Applications

• archivers/quazip was updated.

• deskutils/semantik updated.

• devel/py-qt5-pyqt updated so that the port now pulls in DBus as well. DBus
is needed by nearly all desktop Qt applications, including those written in
Python.

• devel/qcoro had build issues on certain FreeBSD versions, resolved.

• devel/qtcreator updated with each new release.

• devel/qt5 had its infrastructure updated in ports so it does not produce
strange error messages during de-installation.

• graphics/ksnip and related libraries updated to recent releases.

• Matrix clients Nheko (net-im/nheko) and Neochat (net-im/neochat) were
updated following releases and library bumps.

• x11/rsibreak updated; helps prevent injury while writing long quarterly
reports.

Elsewhere

• devel/appstream update supports more application-information.

• devel/cmake prefers generic python3 over versioned-python3, if users have
multiple python3 ports and lang/python3 installed.

• devel/dbus updated.

• graphics/poppler updated several times.

• graphics/ImageMagick (both 6 and 7) updated several times.

• multimedia/gstreamer updated.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

GCC: updating GCC_DEFAULT and other improvements

Links:
GCC Project URL: https://gcc.gnu.org
GCC 11 release series URL: https://gcc.gnu.org/gcc-11/

Contact: <toolchain@FreeBSD.org>
Contact: Gerald Pfeifer <gerald@pfeifer.com>
Contact: Lorenzo Salvadore <salvadore@FreeBSD.org>
Contact: Piotr Kubaj <pkubaj@FreeBSD.org>

• salvadore@ worked on the upgrade of GCC_DEFAULT in Mk/
bsd.default-versions.mk from 10 to 11, opening bug reports based on
antoine@'s exp-runs and fixing some: many thanks to all those that helped
with this task. The GCC_DEFAULT update from GCC 10 to GCC 11 has now been
committed by gerald@ and happened in time for the next quarterly branch.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=258378

• pkubaj@ switched GCC bootstrapping to use Link Time Optimization for GCC
itself for GCC 11 and newer by introducing a new option enabled by default.
Building with LTO_BOOTSTRAP enabled requires significant amounts of memory
and time. How much resources are actually needed depends on your
configuration (e.g. are you building from ports or with poudriere? What is
your architecture?). To give an idea, a user reported needing 5 GiB of
tmpfs, while in PR 265254 a need of about 130 GB of memory is estimated due
to an excessive amount of processes spawning (see also https://gcc.gnu.org/
bugzilla/show_bug.cgi?id=106328). Consider disabling LTO_BOOTSTRAP in favor
of STANDARD_BOOTSTRAP (or disabling BOOTSTRAP altogether) in case that is a
problem.

• pkubaj@ also added lang/gcc12 and lang/gcc13-devel ports and updated lang/
gcc9 to 9.5.

• Help is still needed with these three changes to work through with upstream
GCC (requires src expertise, not ports):

□ upstreaming lang/gcc11/patch-gets-no-more

□ upstreaming lang/gcc11/patch-arm-unwind-cxx-support

□ https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256874

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Valgrind - Numerous bugfixes and updates for 13.1 / 14.0

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

Contact: Paul Floyd <pjfloyd@wanadoo.fr>

A quite significant number of bug fixes have been made to Valgrind on FreeBSD over the past few months. In particular, the i386 version has largely 'caught up' with its bigger brother amd64.

The devel/valgrind-devel port has been bumped up to 3.20.0.g20220612,1 which includes all of the following changes. If you use Valgrind regularly please swtch to valgrind-devel.

Here is a list of changes since the release of Valgrind 3.19.0 (which is the version available with the devel/valgrind port).

• incorrect signal resumption if a signal arrives when Valgrind is saving the
carry flag for a syscall

• fixed reading DWARF debuginfo from PT_LOADs generated by lld post version
9, which splits the RW segment into two parts, this affects mainly shared
libraries (.so files)

• on i386 implement correctly the management of thread GDTs which was
limiting applications to only ever creating 8192 threads

• make the first page of the 'brk' invalid for addressing

• analysis and cleanup of the regression test suite and in particular tweak
the i386 leak tests to not detect possible leaks due to left over pointers
in ECX.

• make coredumps readable by lldb

• improve the setting of errno by C allocating functions

• fix building of Valgrind with llvm-devel (15.0.0)

For FreeBSD 13.1 / 14.0 there are

• syscall wrappers for funlinkat, copy_file_range, swapoff, shm_open2

• add K_INFO handling to fcntl

• add handling for new auxv entries

• added some default suppressions for DRD and Helgrind

There is now an initial version of vgdb invoker support - this allows vgdb to use ptrace to force valgrind to poll for gdb commands. This is not yet available in the ports versions.

That does not leave much in the way of outstanding issues. I expect that 14.0 and newer versions of llvm will keep on requiring support. Apart from that there is

• some small problems with error messages getting the correct source
information

• better core dumps (low priority)

• TLS (thread local storage) handling for Helgrind (difficult if not
impossible)

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Pantheon desktop on FreeBSD

Links:
elementary OS URL: https://elementary.io
Development repository URL: https://codeberg.org/olivierd/ freebsd-ports-elementary

Contact: Olivier Duchateau <duchateau.olivier@gmail.com>

The Pantheon desktop environment is designed for elementary OS. It builds on GNOME technologies (such as Mutter, GNOME Shell, GTK 3 and 4) and it is written in Vala.

The goal is to have a new desktop for users. Some features are not well supported, but we can have full session.

The repository contains Mk/Uses framework elementary.mk, official applications, and curated ports which depend of x11-toolkits/granite (total of 56 new ports).

I have submitted several patches, especially:

• x11-toolkits/granite7

• devel/libgee update to 0.20.5 bug #262893

• sysutils/bamf update to 0.5.6 bug #264203

Open tasks

• Add support of user settings (it is very Ubuntu-centric)

• Finish porting wingpanel-indicator-power (power management)

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Feature Complete Port of Intel’s igt-gpu-tools

Links:
FreeBSD Wiki Project Page URL: https://wiki.freebsd.org/ SummerOfCode2022Projects/ ImprovingTheLinuxKPICompatibilityLayerForTheFreeBSDGraphicsStack
Status Reports URL: https://cdaemon.com/tags/gsoc2022

Contact: Jake Freeland <jfree@freebsd.org>

Intel’s igt-gpu-tools serves as a generic testing suite for drm drivers on Linux. The igt-gpu-tools suite is separated into tests and tools that target kms, memory management, and command submission. The utility provides low-level reporting for transparent tracking of kernel changes and efficient debugging of modern drm drivers.

Porting the project to FreeBSD could introduce greater stability in future releases of FreeBSD’s LinuxKPI-driven drm drivers. A proper kms-driven testing
suite could also increase code output and bring the FreeBSD desktop experience up to speed with the Linux codebase.

The project officially started under FreeBSD’s Google Summer of Code program on
June 13, 2022. My adapted code can compile with non-FreeBSD compatible snippets removed. The plan is to reimplement these stripped components in a POSIX compliant fashion.

Notable incompatible code includes: debugfs, libkmod, libprocps, Linux performance events, and Linux userfaultfd. If you would like to assist in the porting of libkmod or libprocps into the ports tree, don’t hesitate to contact
me.

When the FreeBSD compatible code is complete, I will run the modified igt tests using a host of graphics processors on FreeBSD 14.0-CURRENT. If all is well, the project’s diff will be submitted into the ports tree.

Sponsor: FreeBSD Google Summer of Code

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)