Index: head/en_US.ISO8859-1/htdocs/news/status/report-2020-04-2020-06.xml =================================================================== --- head/en_US.ISO8859-1/htdocs/news/status/report-2020-04-2020-06.xml (revision 54379) +++ head/en_US.ISO8859-1/htdocs/news/status/report-2020-04-2020-06.xml (revision 54380) @@ -1,2878 +1,2878 @@ 04-06 2020
Introduction

This report will be covering FreeBSD related projects between April and June, and covers a diverse set of topics ranging from kernel updates over userland -and ports, as well to third-party work. +and ports, as well as third-party work.

Some highlights picked with the roll of a d100 include, but are not limited to, -the ability to forcibly unmounting UFS when the underlying media becomes +the ability to forcibly unmount UFS when the underlying media becomes inaccessible, added preliminary support for Bluetooth Low Energy, a introduction to the FreeBSD Office Hours, and a repository of software collections called potluck to be installed with the pot utility, as well as many many more things.

As a little treat, readers can also get a rare report from the quarterly team.

Finally, on behalf of the quarterly team, I would like to extend my deepest appreciation and thank you to salvadore@, who decided to take down his shingle. -His contributions not just the quarterly reports themselves, but also the -surrounding tooling to many-fold ease the work, are immeassurable. +His contributions to not just the quarterly reports themselves, but also the +surrounding tooling to many-fold ease the work, are immeasurable.

We hope you find the report as interesting as we have,
Daniel Ebdrup Jensen (debdrup@), on behalf of the quarterly team.

FreeBSD Foundation Deb Goodkin deb@FreeBSDFoundation.org

The FreeBSD Foundation is a 501(c)(3) non-profit organization dedicated to supporting and promoting the FreeBSD Project and community worldwide. Funding comes from individual and corporate donations and is used to fund and manage software development projects, conferences and developer summits, and provide travel grants to FreeBSD contributors. The Foundation purchases and supports hardware to improve and maintain FreeBSD infrastructure and provides resources to improve security, quality assurance, and release engineering efforts; publishes marketing material to promote, educate, and advocate for the FreeBSD Project; facilitates collaboration between commercial vendors and FreeBSD developers; and finally, represents the FreeBSD Project in executing contracts, license agreements, and other legal arrangements that require a recognized legal entity.

Here are some highlights of what we did to help FreeBSD last quarter:

-

COVID-19 Impact to the Foundation

+

COVID-19 Impact on the Foundation

Like other organizations, we put policies in place for all of our staff members to work from home. We also put a temporary ban on travel for staff members. We are continuing our work supporting the community and Project, but some of our work and responses may be delayed because of changes in some of our priorities and the impact of limited childcare for a few of our staff members.

Partnerships and Commercial User Support

We help facilitate collaboration between commercial users and FreeBSD developers. We also meet with companies to discuss their needs and bring that information back to the Project. Not surprisingly, the stay at home orders, combined with our company ban on travel during Q2 made in-person meetings non-existent. However, the team was able to continue meeting with our partners and commercial users virtually. These meetings help us understand some of the applications where FreeBSD is used.

Fundraising Efforts

Last quarter we raised $268,400! Thank you to the individuals and organizations that stepped in to help fund our efforts. We’d like to thank Netflix, employees of Nginx, Beckhoff Automation, and Mozilla Foundation for their large contributions last quarter, which helped bring our 2020 fundraising effort to $339k. We hope other organizations will follow their lead and give back to help us continue supporting FreeBSD.

These are trying times, and we deeply appreciate every donation that has come in from $5 to $150,000. We’re still here giving 110% to supporting FreeBSD!

We are 100% funded by donations, and those funds go towards software development work to improve FreeBSD, FreeBSD advocacy around the world, keeping FreeBSD secure, continuous integration improvements, sponsoring BSD-related and computing conferences (even the virtual events!), legal support for the Project, and many other areas.

Please consider making a donation to help us continue and increase our support for FreeBSD.

We also have the Partnership Program, to provide more benefits for our larger commercial donors. Find out more information about the partnership program and share with your companies!

OS Improvements

A number of FreeBSD Foundation grant recipients started, continued working on, or completed projects during the second quarter. These include:

You can find more details about most of these projects in other quarterly reports.

Staff members also worked on a number of larger projects, including:

Many of these projects also have detailed entries in other quarterly report entries.

Staff members also put in significant effort in many ways other than larger, individual projects. These include assisting with code reviews, bug report triage, security report triage and advisory handling, addressing syzkaller reports, and ongoing maintenance and bug fixes in functional areas such as the tool chain, developer tools, virtual memory kernel subsystem, low-level x86 infrastructure, sockets and protocols, and others.

University of Waterloo Co-op

Foundation co-op students Colin, Tiger, and Yang completed their winter 2020 work term during the second quarter, and continued on with the next school term in their respective programs. Although COVID-19 presented a unique challenge and prompted an abrupt transition to remote work just over half way through the term, all three learned a lot and provided positive contributions to the FreeBSD Project and to the Foundation.

A few projects that were in progress or completed during the work term were committed to the FreeBSD tree in the second quarter.

Continuous Integration and Quality Assurance

The Foundation provides a full-time staff member who is working on improving continuous integration, automated testing, and overall quality assurance efforts for the FreeBSD project.

During the second quarter of 2020, Foundation staff continued improving the Project's CI infrastructure, monitoring regressions and working with contributors to fix the failing build and test cases. The setting up of VM host for CI jobs and staging environment is in progress. We are also working with other teams in the Project for their testing needs. For example, we added jobs for running full tests on non-x86 architectures. We are also working with many external projects and companies to improve their support of FreeBSD.

See the FreeBSD CI section of this report for completed work items and detailed information.

Supporting FreeBSD Infrastructure

The Foundation provides hardware and support to improve FreeBSD infrastructure. Last quarter, we continued supporting FreeBSD hardware located around the world. We started working on getting the new NYI Chicago colocation facility prepared for some of the new FreeBSD hardware we are planning on purchasing. NYI generously provides this for free to the Project.

FreeBSD Advocacy and Education

A large part of our efforts are dedicated to advocating for the Project. This includes promoting work being done by others with FreeBSD; producing advocacy literature to teach people about FreeBSD and help make the path to starting using FreeBSD or contributing to the Project easier; and attending and getting other FreeBSD contributors to volunteer to run FreeBSD events, staff FreeBSD tables, and give FreeBSD presentations.

The FreeBSD Foundation sponsors many conferences, events, and summits around the globe. These events can be BSD-related, open source, or technology events geared towards underrepresented groups. We support the FreeBSD-focused events to help provide a venue for sharing knowledge, to work together on projects, and to facilitate collaboration between developers and commercial users. This all helps provide a healthy ecosystem. We support the non-FreeBSD events to promote and raise awareness of FreeBSD, to increase the use of FreeBSD in different applications, and to recruit more contributors to the Project. As is the case for most of us in this industry, COVID-19 has put our in-person events on hold. In addition to attending virtual events, we are continually working on new training initiatives and updating our selection of how-to guides to facilitate getting more folks to try out FreeBSD.

Check out some of the advocacy and education work we did last quarter:

In addition to the information found in the Development Projects update section of this report, take a minute to check out the latest update blogs:

Keep up to date with our latest work in our Bi-Monthly newsletters.

Mellanox provided an update on how and why they use FreeBSD in our latest Contributor Case Study.

We help educate the world about FreeBSD by publishing the professionally produced FreeBSD Journal. As we mentioned previously, the FreeBSD Journal is now a free publication. Find out more and access the latest issues on the Journal site.

You can find out more about events we attended and upcoming events.

We have continued our work with a new website developer to help us improve our website. Work is nearly complete to make it easier for community members to find information more easily and to make the site more efficient. We look forward to unveiling the refreshed site in Q3.

Foundation Board Meeting

Our annual board meeting was held on Tuesday June 2, 2020. We normally hold this meeting the Tuesday before BSDCan, in Ottawa, Ontario, Canada, but with the company travel ban, and the conference going virtual, our meeting went virtual for the first time. The purpose of the annual board meeting is to hold our board director and officer elections, review work accomplished over the past year, and put together strategic goals for the upcoming 12 months.

The board generally has two all-day board meetings each year, this one, and a more informal one in January, typically held in Berkeley. Both meetings allow us to connect, reevaluate and discuss new ideas, while assessing what we should do to help the Project.

Some of our longer-term goals include Growing User and Developer Communities, Developing Training and OS Course Content, Improving desktop/laptop experience, Promoting FreeBSD (as you can see in all the advocacy work listed above), and Improving Testing Capabilities.

Results of the director and officer elections were:

Find out more about the FreeBSD Foundation Board of Directors on our website.

Legal/FreeBSD IP

The Foundation owns the FreeBSD trademarks, and it is our responsibility to protect them. We also provide legal support for the core team to investigate questions that arise.

Go to the FreeBSD Foundation's web site to find out how we support FreeBSD and how we can help you!

FreeBSD Core Team FreeBSD Core Team core@FreeBSD.org

The FreeBSD Core Team is the governing body of FreeBSD.

The Core Team held 10 meetings during the second quarter of 2020, including a 2020-05-21 joint meeting with members of the FreeBSD Foundation. Here are some highlights from that meeting:

The second annual community survey closed on 2020-06-16. The purpose of the survey is to collect data from the public to help guide the Project's efforts and priorities. As an example, last year's survey results helped initiate the Project's conversion to Git. Thank you to all who took the time to respond. The results will be released soon.

The Core-initiated Git Working Group continued to make progress, but there are still some remaining issues to be worked out with the translation from Subversion. Hopefully the new Git src repository will be ready for use this summer. A beta version has been published for people to test and a preliminary version of a Using Git for FreeBSD Development primer will soon be ready to share. Core, the Git Working Group, and Release Engineering are working towards the goal of releasing 12.2 from the new Git repository.

Following the results of a Core-initiated developer survey, The FreeBSD Project has adopted a new LLVM-derived [code of conduct](https://www.freebsd.org/internal/code-of-conduct.html).

The eleventh FreeBSD Core Team was elected by active developers. From a pool of 23, the 9 successful candidates for core.11 are:

A new Core Team secretary, Muhammad Moinur Rahman (bofh), was unanimously approved by core.11. The outgoing core team met three times with the new core team to help with the transition. Core.10 wishes core.11 a successful term.

FreeBSD Release Engineering Team FreeBSD Release Engineering Team re@FreeBSD.org FreeBSD 11.4-RELEASE announcement FreeBSD 11.4-RELEASE schedule FreeBSD development snapshots

The FreeBSD Release Engineering Team is responsible for setting and publishing release schedules for official project releases of FreeBSD, announcing code slushes, and maintaining the respective branches, among other things.

During the second quarter of 2020, the Release Engineering Team started work on the 11.4-RELEASE cycle, the fifth release from the stable/11 branch. The release cycle went quite smoothly, with both BETA3 and RC3 removed from the schedule. This allowed the final release to occur one week earlier than originally scheduled, which was announced June 16. FreeBSD 11.4-RELEASE is expected to be the final 11.x release.

The FreeBSD Release Engineering Team would like to thank everyone involved in this cycle for their hard work.

Additionally throughout the quarter, several development snapshots builds were released for the head, stable/12, and stable/11 branches.

Much of this work was sponsored by Rubicon Communications, LLC (netgate.com) and the FreeBSD Foundation.

Cluster Administration Team Cluster Administration Team clusteradm@FreeBSD.org Cluster Administration Team members

The FreeBSD Cluster Administration Team consists of the people responsible for administering the machines that the Project relies on for its distributed work and communications to be synchronised. In this quarter, the team has worked on the following:

Work in progress: Continuous Integration FreeBSD Jenkins Instance FreeBSD Hardware Testing Lab FreeBSD CI artifact archive FreeBSD CI weekly report FreeBSD Jenkins wiki Hosted CI wiki 3rd Party Software CI Tickets related to freebsd-testing@ FreeBSD CI Repository Jenkins Admin jenkins-admin@FreeBSD.org Li-Wen Hsu lwhsu@FreeBSD.org

Contact: freebsd-testing Mailing List
Contact: IRC #freebsd-ci channel on EFNet

The FreeBSD CI team maintains the continuous integration system for the FreeBSD project. The CI system firstly checks the committed changes can be successfully built, then performs various tests and analysis over the newly built results. The artifacts from the build jobs are archived in the artifact server for further testing and debugging needs. The CI team members examine the failing builds and unstable tests and work with the experts in that area to -fix the codes or adjust test infrastructure. The details of these efforts +fix the code or adjust test infrastructure. The details of these efforts are available in the weekly CI reports.

During the second quarter of 2020, we continue working with the contributors and developers in the project for their testing needs and also keep working with external projects and companies to improve their support of FreeBSD.

Important changes:

New jobs added: Work in progress: -Please see freebsd-testing@ related tickets for more WIP information, and don't hesistate to join the effort! +Please see freebsd-testing@ related tickets for more WIP information, and don't hesitate to join the effort!

Sponsor: The FreeBSD Foundation

Ports Collection About FreeBSD Ports Contributing to Ports FreeBSD Ports Monitoring Ports Management Team René Ladan portmgr-secretary@FreeBSD.org FreeBSD Ports Management Team portmgr@FreeBSD.org

The Ports Management Team is responsible for overseeing the overall direction of the Ports Tree, building packages, and personnel matters. Below is what happened in the last quarter.

There are currently 2,373 open ports PRs of which 526 are unassigned, for a total of 39,628 ports. In the last quarter there were 10,315 commits to HEAD and 476 to the quarterly branch by respectively 178 and 65 committers. Compared to the quarter before, this means a significant increase in commits and also a slight decrease in open PRs.

During the last quarter, we welcomed Hiroki Tagato (tagattie@). We said goodbye to seanc@, zleslie@, gnn@ and salvadore@.

A few default versions got bumped:

It is now possible to write pkg scripts in Lua instead of sh.

They have two advantages over their sh versions:

Some user-facing packages were also updated:

During the last quarter, antoine@ ran 55 exp-runs to test port version updates, make liblzma use libmd, flavor devel/scons and Lua ports, add and update library functions in the base system, make malloc.h usable again, remove as(1) from the base system, and augment sed(1) with -f.

FreeBSD Office Hours Office Hours on the FreeBSD Wiki Poll: What time would you prefer Office Hours be at live.FreeBSD.org: Aggregation of Live streams Allan Jude allanjude@freebsd.org

Starting on the first of April 2020, the FreeBSD project has started hosting regular video streams to foster greater communication within the wider FreeBSD community. The first of these sessions took the form of a public question and answer session, which drew over 60 participants. A second session was held two weeks later at a time more appropriate for those in Asia, but only drew 20 participants. With the help of the FreeBSD Foundation, we ran a poll to discover what times worked best for the greatest number of people.

On May 13th the FreeBSD Foundation hosted a session where the community could ask questions of or about the foundation. On May 27th many of the candidates for the new FreeBSD Core Team joined an office hours session to answer questions from the community. Finally on June 24th another general question and answer office hours was held.

Each office hours session consists of a video meeting of some FreeBSD developers or other subject matter experts, live streamed along with an IRC chat room for viewers to pose questions to the panel. The stream is recorded and posted to the official FreeBSD youtube channel.

If you would like to host an office hours session, please contact:

Sponsor: ScaleEngine Inc. (video streaming)

Quarterly Status Reports Team Quarterly Status Reports quarterly@FreBSD.org Daniel Ebdrup Jensen debdrup@FreeBSD.org Quarterly status reports Git repository -

The Quarterly Status Reports Team collects and publish the reports that you are +

The Quarterly Status Reports Team collects and publishes the reports that you are reading right now.

Many improvements have been done recently and thus we believe it is useful that the Quarterly Status Reports Team submits a report. Not all the changes below are specific to the last quarter, but we list them here anyway since we did not write an entry for earlier reports.

We would like to thank philip@, from the postmaster team, for having created the freebsd-quarterly-calls@ mailing list and the quarterly-submissions@ address for us.

FreeBSD on Microsoft HyperV and Azure FreeBSD on MicrosoftAzure wiki FreeBSD on Microsoft HyperV FreeBSD Integration Services Team bsdic@microsoft.com Wei Hu whu@FreeBSD.org Li-Wen Hsu lwhsu@FreeBSD.org

HyperV socket for FreeBSD implemented by Wei was checked into FreeBSD head branch on May 20th as r361275. It supports guest/host communications without the need for networking. Some HyperV and Azure features rely on this to be available in guests.

Details of HyperV Socket is available here.

This project is sponsored by Microsoft.

Li-Wen is working on the FreeBSD release code related to Azure for the -CURRENT, 12-STABLE and 11-STABLE branches. The work-in-progress is available here. The 12.1-RELEASE image on Azure Marketplace is published. The work on the 11.4-RELEASE image on Azure Marketplace is in progress.

This project is sponsored by The FreeBSD Foundation.

Git Migration Working Group Git conversion tooling repo FreeBSD-git mailing list Beta doc git repo Beta ports git repo Beta src git repo Ed Maste emaste@FreeBSD.org Warner Losh imp@FreeBSD.org Ulrich Spörlein uqs@FreeBSD.org

Work continues on FreeBSD's migration from Subversion to Git. Ulrich has iterated on updates to svn2git in order to improve the fidelity of the conversion, particularly in regards to vendor (contrib) code updates. We believe the conversion is now at an acceptable state, but may make minor adjustments if additional issues are found. We expect to push modifications to the converter every two weeks (first and third Sunday of the month). This means that commit hashes in the beta repo will remain stable for at least two weeks at a time, to allow others to test and experiment with the beta repo.

We are now working on updating FreeBSD processes and documentation. This includes:

Those with an interest in the migration to Git are encouraged to subscribe to the FreeBSD-git mailing list and test out the beta src, ports, and/or doc repositories.

-

You are also welcome check out the wiki, issues, README and other documentation at the +

You are also welcome to check out the wiki, issues, README and other documentation at the Git conversion tooling repo.

We expect to be ready for the migration in the next quarter.

Sponsor: The FreeBSD Foundation (in part)

Lua Usage in FreeBSD Ed Maste emaste@FreeBSD.org Kyle Evans kevans@FreeBSD.org Ryan Moeller freqlabs@FreeBSD.org

Lua is a small, efficient scripting language that FreeBSD imported before FreeBSD 12.0 for use in the bootloader. Since then, several projects outside of the bootloader have gained some amount of traction with Lua usage:

FreeBSD Lua ("flua") is a version of the lua interpreter that has several modules built-in for convenient usage within the base system. flua is installed with a non-standard name and in a location not included in $PATH so that it is not accidentally found by third-party software or configure scripts. The FreeBSD project makes no guarantees about upgrade cadence or module stability. That said, it is available for use by downstream projects and FreeBSD users aware of those limitations.

Previous work with flua includes, for example, adding libucl support and future work includes libifconfig support for scripting usage.

People interested in working with Lua in FreeBSD are welcome to get in contact to discuss other project ideas. To name a couple of potential projects, some interesting modules that have not been started but could prove useful (listed in no particular order):

Linux compatibility layer update Edward Tomasz Napierala trasz@FreeBSD.org

Earlier Linuxulator work focused on code cleanups and improving diagnostic tools. Work has now shifted from cleanups to fixing actual applications. Current status is being tracked at Linux app status Wiki page. Initial focus is on applications that don't involve X11, mostly because they tend to be easier to test and debug, and the bug fixes are not application-specific.

Example problems fixed include buggy madvise(2) handling, which could break applications linked against jemalloc; uname(2) returning wrong results for 32 bit apps, which caused problems for Steam; recvmsg(2) and accept(2) being broken in some circumstances, which was breaking Redis; and missing support for SO_REUSEPORT, SO_SNDBUFFORCE, SO_RCVBUFFORCE, and SO_PROTOCOL, which spammed the log files when running the Python regression test suite. The default soft open files limit is now automatically adjusted to 1024, as several Linux apps iterate over all the file descriptors up to that limit instead of using closefrom(2).

There's ongoing work on cleanups and the debugging framework for Linux compatibility, such as logging warnings for unrecognized system call parameters, or adding the compat.linux.debug sysctl to turn the warnings off.

The Linux Test Project tests that are being run as part of the the FreeBSD Continuous Integration infrastructure has been upgraded to 20200605 snapshot. This raised the number of test cases from 3670 to 3749, and, predictably, also the number of failures, from 583 to 647.

There's still a lot to do:

Sponsor: The FreeBSD Foundation

NFS over TLS implementation Rick Macklem rmacklem@freebsd.org

In an effort to improve NFS security, an internet draft which I expect will become an RFC soon specifies the use of TLS 1.3 to encrypt all data traffic on a Sun RPC connection used for NFS.

Although NFS has been able to use sec=krb5p to encrypt data on the wire, this requires a Kerberos environment and, as such, has not been widely adopted. It also required that encryption/decryption be done in software, since only the RPC message NFS arguments are encrypted. Since Kernel TLS is capable of using hardware assist to improve performance and does not require Kerberos, NFS over TLS may be more widely adopted, once implementations are available.

The project to implement this has largely been completed. The code will slowly be merged into head/current and at least the kernel portion should be in FreeBSD-13.

To support clients such as laptops, the daemons that perform the TLS handshake may optionally handle client X.509 certificates from a site local CA. There are now exports(5) options to require client(s) to provide a valid X.509 certificate.

The code is now available for testing. See: https://people.freebsd.org/~rmacklem/nfs-over-tls-setup.txt Setting up system(s) for testing is still a little awkward, as explained by the above rough document.

The main limitation in the current implementation is that it uses TLS1.2 and not TLS1.3. This should change once the KERN_TLS rx patch includes TLS1.3 support. Also, testing of pNFS configurations has not yet been done, but will be tested soon.

Third party testing would be appreciated.

SoC audio framework and more audio drivers rk3399_audio Oleksandr Tymoshenko gonzo@FreeBSD.org

SoC audio framework made a good progress since last report.
Support for AUX devices was added (devices like auxiliary amplifiers that are not part of main CODEC chip).
To verify the framework design following audio drivers were added: recording support for RT5640 CODEC(Firefly-RK3399), Allwinner I2S, Alwinners sun8i and A64 CODECs (Pine A64+), both recording and playback.
Current work in progress is RK3328 CODEC (Rock64) and ES8316 CODEC (RockPro64 and Pinebook Pro).

bhyve - NVMe emulation improvements bhyve NVMe reviews Chuck Tuffli chuck@freebsd.org

The University of New Hampshire InterOperability Laboratory (a.k.a. UNH IOL) develops a suite of tests to determine if an NVMe device conforms to the specification and is interoperable with other NVMe products. This quarter, I undertook getting bhyve's emulated NVMe device to pass the mandatory tests. Changes include:

This was also a good opportunity to restructure parts of the code to make it more modular and easier to enhance. This includes

You can help by testing and/or commenting on the code reviews.

Bluetooth Support Marc Veldman marc@bumblingdork.com

Bluetooth is a wireless technology for creating personal networks, connecting peripherals like keyboards and mice but also speakers and heart rate monitors.

FreeBSD has limited Bluetooth Basic Rate (BR) support and no functional Bluetooth Low Energy (LE) support.

During this quarter many small improvements have been made to help the development of Bluetooth LE support. A number of commands have been added to hccontrol(8), mainly to do LE functions. It is now possible to scan for LE devices within range using hccontrol. A panic that occurred when enabling LE support has also been fixed.

Work is still needed to add Attribute Protocol (ATT) and Generic Attribute Profile (GATT) support.

DRM Drivers Update drm-kmod Emmanuel Vadot manu@FreeBSD.Org

The drm drivers for FreeBSD 13-CURRENT have been updated to match Linux 5.3 This brings us a little bit closer to the last LTS release of Linux (5.4).

The current plan is to first update the driver to match 5.4 and then look at making it work on FreeBSD-12-STABLE to have it ready for the 12.2 release.

Sponsor: The FreeBSD Foundation

DTS Update Emmanuel Vadot manu@FreeBSD.org

DTS files (Device Tree Sources) were updated to be on par with Linux 5.7 for HEAD and 5.6 for the 12-STABLE branch.

ENA FreeBSD Driver Update ENA README Michal Krawczyk mk@semihalf.com Artur Rojek ar@semihalf.com Marcin Wojtas mw@semihalf.com

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:

Sponsor: Amazon.com Inc

Forcible Unmount of UFS/FFS Filesystems on Disk Failure Phabricator Details Chuck Silvers chs@freebsd.org Kirk McKusick mckusick@mckusick.com

Commit -r361491 on May 25, 2020 enables a UFS file system to do a forcible unmount when the underlying media fails or becomes inaccessible. For example when a USB flash memory card hosting a UFS file system is unplugged.

The rest of this report describes in more detail how forcible -unmounts are done. Suprisingly, less than 500 lines of file +unmounts are done. Surprisingly, less than 500 lines of file system code were added or changed.

The strategy for handling disk I/O errors when soft updates are enabled is to stop writing to the disk of the affected file system but continue to accept I/O requests and report that all future writes by the file system to that disk actually succeed. Then initiate an asynchronous forced unmount of the affected file system.

There are two cases for disk I/O errors:

For ENXIO, we can just clear the error and continue, because we know that the file system cannot affect the on-disk state after we see this error. For EIO or other errors, we arrange for the geom_vfs layer to reject all future I/O requests with ENXIO just like is done when the geom_vfs is orphaned. In both cases, the file system code can just clear the error and proceed with the forcible unmount.

This new treatment of I/O errors is needed for writes of any buffer that is involved in a dependency. Most dependencies are described by a structure attached to the buffer's b_dep field, but some are created and processed as a result of the completion of the dependencies attached to the buffer.

Clearing of some dependencies require a read. For example if there is a dependency that requires an inode to be written, the disk block containing that inode must be read, the updated inode copied into place in that buffer, and the buffer then written back to disk.

Often the needed buffer is already in memory and can be used. But if it needs to be read from the disk, the read will fail, so we fabricate a buffer full of zeroes and pretend that the read succeeded. This zero'ed buffer can be updated and "written" back to disk.

The only case where a buffer full of zeros causes the code to do the wrong thing is when reading an inode buffer containing an inode that still has an inode dependency in memory that will reinitialize the effective link count (i_effnlink) based on the actual link count (i_nlink) that we read. To handle this case we now store the i_nlink value that we wrote in the inode dependency so that it can be restored into the zero'ed buffer thus keeping the tracking of the inode link count consistent.

Because applications depend on knowing when an attempt to write their data to stable storage has failed, the fsync(2) and msync(2) system calls need to return errors if data fails to be written to stable storage. So these operations return ENXIO for every call made on files in a file system where we have otherwise been ignoring I/O errors.

Sponsor: Netflix

i.MX 8M support D25274 Oleksandr Tymoshenko gonzo@FreeBSD.org

i.MX 8M is the family of application processors from NXP based on Arm® Cortex®-A53 and Cortex-M4 cores. The initial code drop for the platform support includes CCM driver and clock implementation, GPC driver, clock tree for i.MX 8M Quad. Most of the drivers from i.MX 6 can be reused for i.MX 8M systems with relatively minor modifications. Common changes include adding clock support and extending list of FDT compat strings.

With the linked patch FreeBSD successfully booted to multiuser with NFS root on Nitrogen8M SBC.

Intel wireless and 11ac update Initial project announcement The freebsd-wireless mailing list Bjoern A. Zeeb bz@FreeBSD.org

The Intel Wireless cards are one of the most commonly used -and ask for in FreeBSD notebooks. +and asked for in FreeBSD notebooks.

This project has three main goals:

The first one is needed as iwm(4) currently does not support the latest generations of Intel Wireless cards at all. The second is needed as in FreeBSD iwm(4) does not even support 802.11n. The third one we want to catch up and use the improvements the new Wifi standard offers, e.g., speed.

One of the decisions made was: rather than improving iwm(4) this work uses the dual-licensed native Linux driver under BSD license and the linuxkpi framework to stay as close to upstream as possible as a first step. This will give us several advantages, such as, the full support for all cards, quick support for new chipsets, vendor bug fixes, but also the ability to contribute back.

At this point the lower level hardware attachments and the firmware loading and initialisation works. I plan to release a patchset for testing before mid-July, you can see if your currently supported or unsupported hardware will be detected. This first cut will not support any wireless operation yet, which will follow later in the year.

If you want to help testing, please watch the freebsd-wireless list.

Sponsor: The FreeBSD Foundation

 amd64 5-Level Paging Structures support Patch Intel SDM Intel whitepaper Konstantin Belousov kib@FreeBSD.org

Since its introduction, x86 Long Mode (AKA 64bit execution mode, amd64 in FreeBSD terminology) uses 4-level paging structures, which provides 48 bits of virtual address space (LA48). FreeBSD evenly divides the space between userspace and kernel, giving both 47 virtual address bits.

In near future Intel CPUs will start providing 5-level paging structures, i.e. giving 57 bits for virtual addresses (LA57). This means, with preservation of the existing divide between KVA and UVA, 56 bit for UVA, or 2^9 = 512 times more virtual memory.

The amd64 pmap was modified to support both LA48 and LA57, defaulting to LA57 if hardware supports it. The tunable is provided to force using LA48 even if hardware can do LA57.

The most interesting part of the patch is the switch from boot paging mode to LA57. Loaders, either legacy or UEFI, pass control to the kernel in Long Mode, which implies that the paging is turned on. This -neccessarily means that it is LA48 mode. SDM states that paging mode +necessarily means that it is LA48 mode. SDM states that paging mode cannot be switched while Long Mode is active, so kernel has to create new page table structures, turn Long Mode off, then load new %cr3 and finally re-enable Long Mode.

I decided to only provide the larger virtual address space to usermode for the initial step, leaving KVA layout intact. The main motivation is that changing KVA arrangements requires changing the auto-tuning settings, which deserve separate work. Another argument for it is that most of the kernel memory is non-swappable, so cannot be over-commited. We have 2:1 ratio of useful KVA to physical memory (due to direct map), and until machines get more physical address lines, increasing KVA is not useful.

After this was decided, creating a 5-level paging structure for kernel pmap from existing 4-level one is quite straightforward; we need to add one page for top level, create one PML5 entry to point to existing PML4 page, and create the famous self-referential entry for vtopte()/vtopde().

Care was taken to provide binary compatible layout of UVA for binaries that cannot be executed correctly with larger address space. For instance, programs could have knowledge about used bits in the addresses and used upper bits for other data, or implemented compressed pointers. Even if system runs in LA57 mode, specific binary can request LA48-compatible UVA by procctl(2) or by the flag in the FreeBSD features ELF note.

Since I do not have access to a machine with LA57, development was done using QEMU. It would be interesting to try it on the real hardware.

Sponsor: The FreeBSD Foundation

 Not-transparent superpages Patch Konstantin Belousov kib@FreeBSD.org

FreeBSD already provides excellent support for superpages, in a manner completely transparent to applications. It tries to -proactively prevent fragmentation, reserves contigous runs of the +proactively prevent fragmentation, reserves contiguous runs of the physical pages for linear allocations in managed objects, and auto-promote runs of small pages when they form complete superpage.

The shortcomings of this approach directly follows from its strength: some applications want to get guaranteed superpage mappings, typically because the underlying physical memory is also offloaded into a hardware which also has memory mapping unit. For instance, Infiniband RMDA adapters do memory registration and remapping, which is more efficient with large pages. In such cases transparent (non-guaranteed) support cannot be used.

The extension was developed for POSIX shared memory subsystem to allow the creator request that the shared memory object was backed by physically contiguous pages, with runs of specified size. The mmap(2) syscall is aware of such objects, and if the requested mapping is properly aligned, it will be served by superpages.

-

The new type of the shared memory objects are backed by modified -a physical pager, which only allocates contigous physical memory. The +

The new type of the shared memory objects are backed by a modified +physical pager, which only allocates contiguous physical memory. The VM ensures that mappings of the objects are never split (clipped) on a non-superpage boundary. The fault handler is specially optimized to be very fast by quickly installing the superpage PTE, and to avoid touching all small pages constituing it.

Currently the required pmap support is provided for amd64 with 2M and 1G superpage sizes.

Sponsor: The FreeBSD Foundation

 NXP ARM64 SoC support Marcin Wojtas mw@semihalf.com Artur Rojek ar@semihalf.com Dawid Gorecki dgr@semihalf.com

The Semihalf team initiated working on FreeBSD support for the NXP LS1046A SoC

LS1046A are quad-core 64-bit ARMv8 Cortex-A72 processors with integrated packet processing acceleration and high speed peripherals including 10 Gb Ethernet, PCIe 3.0, SATA 3.0 and USB 3.0 for a wide range of networking, storage, security and industrial applications.

Completed since the last update:

Todo:

Sponsor: Alstom Group

amd64 pmap Fine-grained pv lists locking Patch Konstantin Belousov kib@FreeBSD.org

FreeBSD kernel Virtual Memory subsystem handles 'normal' application memory, i.e. anonymous or file-backed shared and private mappings, with so called managed pages. Managed page is fully controlled by VM, which tracks it status. In particular, managed page can be made read-only for write-back to the file, or unmapped for reuse (paging).

The machine-dependent VM layer, pmap, must support managed pages, for instance it must provide operations such as pmap_remove_write() to downgrade all mappings to read-only, or pmap_remove_all() to unmap the page from all address spaces. To implement this kind of operations, while not causing the overhead of scanning all page tables, pmap must track existing mappings of the page. The tracking is done by allocating a small data structure 'pv entry' per mapping, and linking all pv entries for the given page into pv list.

Since pv entries come from context of different address spaces, pmap must provide synchronization to guarantee correctness of the list structures. Current pmap allocates one mutex per one 2M physical superpage in NUMA configurations, and MAXCPU == 256 locks hashed by the page physical address for non-NUMA. The end result is often undeserved lock aliasing causing pv list locks contention, since all 4k pages in the 2M superpage share the same lock, and reservations -typically cause adjasted pages to come from the same superpage. +typically cause adjusted pages to come from the same superpage.

The proposed patch creates a new kernel synchronization primitive called one byte mutex, which is embedded into the currently unused padding in machine-dependent portion of the struct vm_page. This way each page gets dedicated pv list lock without using any more memory. In the ever-important buildkernel benchmark on non-NUMA config, this change provides 2x reduction of the system time.

One complication is that old locking distribution scheme made a natural fit for superpages promotion and demotion, since all embedded small pages shared the same pv list lock, and the operations basically fold/unfold corresponding pv entries. Now the promotion and demotion operations require taking all locks for constituent small pages, which provides small but measurable impact on them. It is possible to optimize it further by providing the 'superlock' on the first page from the superpage run, but the affected operations are relatively rare so that it is not even obvious that implementing the optimization would not slow down other pathes.

Another important nuance of the pv entries handling is that sometimes pv entries allocator must not fail. Typically this is required when kernel makes a call to pmap_enter() which must establish new mapping, and for managed page this includes allocating the pv entry if existing cannot be reused. If allocator cannot get a fresh page from the vm_page_alloc(9), it opts to destroy some other managed mapping to either get a reusable pv entry from current pmap, or destroy enough managed mappings from some other pmap to free whole page.

To do the reclamation, currently all pages from which with pv entries are allocated, are linked in the global pv chunk list, which is protected by global (per-NUMA domain) mutex. Any allocation or free of pv entry has to lock the mutex, which is apparently a contention point for large machines.

Patch removes the global list of chunks, instead linking all pmaps in the global list like it is done on i386 (but for different reason). Now the global lock is only taken for pmap creation and free, which corresponds to fork/exec and exit of a process, and when pv allocator starts reclaiming from other pmaps (which is normally does not happen).

Sponsor: The FreeBSD Foundation

Lockless routing lookups and scalable multipath Implementation of scalable multipath Alexander Chernikov melifaro@FreeBSD.org

The primary goal of this work is to bring scalable routing multipath implementation, enabled by default. Another goal is enabling high-performance routing lookups.

Multipath will close long-standing feature gap that modern networking OS must have. Lockless routing lookups will remove lookup bottlenecks, improve both dataplane and control plane performance for the setups with large number of routes.

Background

The initial routing kpi was introduced back in 1980. It was a nice generic approach back then, as no one knew how the protocols would evolve. It has been enormously successful as it was able to survive for 20+ years.

Unfortunately, this kpi does not try to protect subsystem internals from the outside users, resulting in tight coupling with other subsystems. As a result, making changes is hard, leading to compromises and piling technical debt.

Implementation overview

Most changes are based on introduction of the concept of nexthops. Nexthops are separate datastructures, containing all necessary information to perform packet forwarding such as gateway, interface and mtu. They are shared among the routes, providing more pre-computed cache-efficient data while requiring less memory. Interested reader can find more detailed description in D24141. Another overview can be found in Nexthop object talk describing Linux implementation.

Multipath implementation extends nexthop concept further by introducing nexthop groups.

Each route has a pointer to either nexthops or a nexthop group, decoupling lookup algorithm from the routing stack internals. Both nexthops and nexthop groups are immutable and use epoch(9)-backed reclamation.

-

A pre-requisite for lockless routing lookup is the introduction of modular lookup framework, allowing to attach any longes-prefix-match algorithm implementation to any IPv4/IPv6 fib. +

A pre-requisite for lockless routing lookup is the introduction of modular lookup framework, allowing to attach any longest-prefix-match algorithm implementation to any IPv4/IPv6 fib.

Currently there are plans to use modified DIR-24-8 algorithm from DPDK for both IPv4 and IPv6 families as an example of base lockless implementation.

Status

 ZSTD Compression in ZFS Allan Jude allanjude@freebsd.org

Zstandard (ZSTD) is a modern high-performance compression algorithm designed to provide the compression ratios of gzip while offering much better performance. ZSTD has been adopted in FreeBSD for a number of other uses, including compressing kernel crash dumps, as a replacement for gzip or bzip for compressing log files, and for future versions of pkg(8).

This effort to complete the integration of ZSTD into ZFS is sponsored by the FreeBSD Foundation.

Integrating ZSTD into ZFS will further extend the transparent compression feature of ZFS by offering higher compression ratios without the performance penalty associated with gzip. ZSTD offers compression levels ranging from 1 (low compression) to 22 (maximum compression), plus ZSTD-Fast levels that offer less compression but even greater speed. This will allow the storage administrator to select the performance-vs-compression tradeoff that best suits their needs.

Tasks remaining to be completed:

Sponsor: The FreeBSD Foundation

CheriBSD 2020 Q2 CHERI-CPU DARPA FETT Bug Bounty Program Alex Richardson arichardson@FreeBSD.org Andrew Turner andrew@FreeBSD.org Brooks Davis brooks@FreeBSD.org Edward Tomasz Napierala trasz@FreeBSD.org Jessica Clarke jrtc27@FreeBSD.org John Baldwin jhb@FreeBSD.org Robert Watson rwatson@FreeBSD.org Ruslan Bukin br@FreeBSD.org

CheriBSD extends FreeBSD to implement memory protection and software compartmentalization features supported by the CHERI instruction set extensions.

Support for CHERI-RISC-V in CheriBSD has continued to mature this quarter in tandem with refinements to the CHERI-RISC-V architecture. We have recently made CheriBSD's "pure capability" (CheriABI) process environment the default ABI rather than a compatibility layer. It has grown support for:

At this point, CHERI-RISC-V support in CheriBSD is generally on par with support for CHERI-MIPS.

Much of this effort has been focused on preparing CheriBSD on CHERI-RISC-V for inclusion as a demonstrator system in DARPA's Finding Exploits to Thwart Tampering (FETT Bug Bounty program).

In addition, work has begun this quarter on porting CheriBSD to Arm's Morello SoC. Morello is a prototype demonstrator board which adds CHERI extensions to ARMv8-A.

We've recently switched to a dev-branch model where active work takes place on the dev branch and we periodically merge to master with synchronization between CheriBSD and dependencies like CHERI-LLVM.

For those interested in what it's like to program for CHERI, we've recently released a CHERI C/C++ Programming Guide.

Continuous Integration on !x86 Edward Tomasz Napierala trasz@FreeBSD.org

For quite a while the FreeBSD CI infrastructure has been running FreeBSD builds and regression tests, making it easy to spot regressions. While CI was building images for all architectures, the regression tests were only run on amd64 and i386, which means they couldn't detect architecture-specific runtime breakage on non-x86 architectures. This poses a problem not only for FreeBSD itself, but also for people working on FreeBSD forks for !x86, such as the CHERI project at University of Cambridge and SRI International.

The goal of this project is to run regression tests on the remaining architectures supported by FreeBSD: ARM, ARM64, MIPS, POWER, and RISC-V. The tests are being run using common, mostly machine-independent scripts. Those required some changes to make it possible to use QEMU in addition to Bhyve, the hypervisor used for x86 tests. The sysutils/u-boot-qemu-arm and sysutils/u-boot-qemu-arm64 ports were added to the Ports Collection. Finally, each of the architectures required some tweaks, to account for different configuration requirements - for example the MIPS kernel doesn't support VirtIO disks, or even AHCI, whereas on ARM64 the U-Boot gets confused with more than one VirtIO disk.

On ARM, we're currently at 52 failures and 590 skipped tests, of 5925 tests ran (https://ci.freebsd.org/job/FreeBSD-head-armv7-test/lastCompletedBuild/testReport/). On ARM64 it's 19 failures and 160 skipped (https://ci.freebsd.org/job/FreeBSD-head-aarch64-test/lastCompletedBuild/testReport/). On MIPS it's 172 failures and 734 skipped (https://ci.freebsd.org/job/FreeBSD-head-mips64-test/lastCompletedBuild/testReport/). For POWER, and RISC-V the results are not available yet.

Remaining work:

Sponsor: DARPA

FreeBSD/RISC-V Project Wiki Mitchell Horne mhorne@FreeBSD.org

Contact: freebsd-riscv Mailing List
Contact: IRC #freebsd-riscv channel on freenode

The FreeBSD/RISC-V project is providing support for running FreeBSD on the RISC-V Instruction Set Architecture. Since RISC-V is still a young and evolving platform, one of our goals is to have FreeBSD be a well-supported option for users as RISC-V hardware increases in availability.

This quarter saw a number of improvements to the boot process.

The physmem interface used by arm and arm64 to enumerate physical memory resources was moved to machine-independent code and adopted on RISC-V. As a result, the kernel is now able to detect and exclude physical memory reserved by devices or firmware. A bug that prevented the kernel from using physical memory below its load address was fixed. This typically did not manifest in much waste, as the kernel is loaded 2MB after the start of physical memory by default. In future boot configurations, the impact would have been much larger.

Our port for OpenSBI was updated to v0.8, bringing several new features and fixes. In particular, it brought the Hardware State Management (HSM) extension, which can be used to start and stop CPUs. FreeBSD will now use this extension whenever it detects that it is available.

There has also been a lot of work done to port FreeBSD's standard bootloader, loader(8), to RISC-V. This has big advantages in terms of boot flexibility, and brings us closer to what's needed to produce official FreeBSD/RISC-V release images. By leveraging UEFI support from u-boot, loader.efi can be used in a manner similar to arm and arm64. Next quarter will likely bring u-boot ports for RISC-V targets, pending the v2020.07 release. Booting the kernel directly via SBI firmware will continue to be supported.

Import of new implementation of bc and dc Official repository Repository mirror on GitHub Stefan Esser se@FreeBSD.org Gavin D. Howard yzena.tech@gmail.com

A new version of bc and dc has been imported into FreeBSD-CURRENT and enabled by default. An import into 12-STABLE is planned before the end of July, but it will not be enabled by default (will require "WITH_GH_BC=yes" to be set in /etc/src.conf).

This version has been developed by Gavin D. Howard with the goal to provide a highly portable and POSIX compatible implementation. It offers GNU bc compatibility and should be a drop-in replacement for the bc in FreeBSD, except for standard-violating behavior of the bc currently in FreeBSD (e.g., the modulo operator).

Additional features:

The only dc feature not supported by the dc is the execution of sub-processes, since the author considers it a security hazard for a calculator to have.

This code is also available as a port and package (math/gh-bc or gh-bc), e.g. for use with a FreeBSD binary release.

Binutils Retirement GPL in Base wiki page Ed Maste emaste@FreeBSD.org

We have been working on migrating to a modern and copyfree or permissively licensed toolchain for quite some time. In the last quarter we retired two obsolete GNU bintuils: objdump, and as.

Many uses of objdump can be replaced with readelf, and llvm-objdump is also available in the base system. Ports that depend on objdump have been updated to rely on the GNU binutils port or package.

The GNU as utility was used by both the base system and by ports. As with objdump, ports that require GNU as have generally been updated to depend on binutils. One file in the base system (skein_block_asm.s) proved troublesome during earlier attempts to migrate to using Clang's integrated assembler (IAS). However, after the update to Clang 10 (and with some trivial modifications to the source) IAS can assemble the file.

Both GNU as and objdump have been removed from FreeBSD-CURRENT and will be absent from FreeBSD 13.0.

TODO

The final task in the binutils retirement project is to remove GNU GDB 6.1. It is currently retained for crashinfo(8).

Sponsor: The FreeBSD Foundation

Run-Time Dynamic Linker improvements Konstantin Belousov kib@FreeBSD.org

Rtld gets some number of small bug fixes and improvements.

RTLD_DEEPBIND dlopen(3) flag was implemented, despite being a strange and even unsafe idea, for compatibility with glibc.

Several improvements to the direct execution mode were made. Most interesting are perhaps the '-v' switch to report some configuration parameters for rtld, the ability to specify argv0 different from the executed binary name, and fixes to properly set osrel/ABI for the directly executed binary.

The link_map structure that is used by tools that need to know the list of loaded shared objects (like gdb and wine) was made more compatible with glibc, while keeping existing FreeBSD ABI intact.

In the course of the link_map work, it become apparent that rtld sometimes needs to report presence of features that cannot be deduced by just a runtime test for symbol presence or for function behavior. For that, a scheme of reporting features with uniformingly named symbols was designed - see the rtld(1) man-page (in CURRENT) for an explanation.

Position-independent (PIE) binaries on FreeBSD are now marked with the DF_1_PIE DT_FLAG1 flag. Otherwise, such binaries are just ET_DYN objects and it is quite hard to distinguish proper dynamically shared object (DSO) from PIE binary. The problem is that for binaries, the static linker strips some information which is required for proper loading as a DSO, and additonally, binaries contains relocations like copy-relocations that cannot be handled for non-main binaries at all.

With the flag addition, rtld properly detects binaries and refuses to load them with dlopen() or as DT_NEEDED dependency. ldd(1) also misdetected PIE vs. DSO, and required a fix to parse dynamic segments to not try to dlopen() them.

Sponsor: The FreeBSD Foundation

VHDX support in mkimg(1) Oleksandr Tymoshenko gonzo@FreeBSD.org

VHDX is the successor of Microsoft's VHD virtual drive file format. It increases maximum capacity of the virtual drive to 64TB and introduces features to better handle power/system failures.
VHDX is the required format for 2nd generation Hyper-V VMs.

FreeBSD Translations on Weblate Translate FreeBSD on Weblate wiki FreeBSD Weblate Instance Danilo G. Baio dbaio@FreeBSD.org Edson Brandi ebrandi@FreeBSD.org

This quarter was improved the renderization of RTL (Right-to-left) languages on the FreeBSD Documentation. We faced this issue after the first RTL language joined the translations effort (fa_IR).

We are looking forward to receive more languages and translators to the project as well.

Q2 2020 Status

Languages

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.

Bastille Bastille GitHub Bastille Templates Bastille Website Christer Edwards christer.edwards@gmail.com

What is Bastille?

Bastille is an open-source system for automating deployment and management of containerized applications on FreeBSD.

Bastille Templates automate container setup allowing you to easily reproduce containers as needed.

Bastille is available in ports at sysutils/bastille.

Q2 2020 Status

In Q2 2020 Bastille merged some exciting new features into GitHub. Changes include:

sysutils/bastille was updated to 0.6.20200414 (latest).

New Bastille templates added this quarter include:

Everything mentioned here was done under COVID-19 quarantine. Special thanks to everyone that contributed during this time.

KDE on FreeBSD KDE FreeBSD KDE Community FreeBSD Adriaan de Groot kde@FreeBSD.org

The KDE on FreeBSD project packages the software produced by the KDE Community for FreeBSD. The software includes a full desktop environment KDE Plasma, IDE KDevelop, a PIM suite Kontact and hundreds of other applications that can be used on any FreeBSD desktop machine.

This quarter has been an ever-so-peculiar one. While we are used to working remotely, collaborating over the internet to update the ports tree, it's qualitatively different when the whole world locks down. Meanwhile, software continues to be released, so this quarter the kde@ team:

The kde@ team would like to thank Antoine for many exp-runs, mikael@ for useful tips, swills@ for patience and kai@ for dealing with WebEngine.

The next big round of updates for the KDE stack is slated: CMake 3.18, Qt 5.15 LTS, and KDE Frameworks 5.71.

Haskell on FreeBSD Haskell language homepage Ports development repo Gleb Popov haskell@FreeBSD.org

Haskell is a general-purpose strictly-typed pure functional language. The Haskell on FreeBSD projects strives to provide the up-to-date Haskell toolchain as well as various application written in this language.

This quarter brought the long-awaited GHC update, which is now at version 8.8.3. Along the compiler, the Haskell build system frontend, cabal-install, was also upgraded to 3.0.2.0. During this update, numerous Haskell ports were updated too.

All existing ports of Haskell applications were migrated to USES=cabal, which implements Go-style build proccess - all dependencies are compiled as part of the build. As a consequence, ports for Haskell libraries have been deprecated and removed.

Upgrading GHC became a tedious task for a single person, so a new GitHub repository was created under the FreeBSD organization - freebsd-ports-haskell. Right now, work is being done on preparing another GHC upgrade in the ghc-upgrade-810 branch. Any contributions are welcome.

rtsx - Porting driver for Realtek SD card reader from OpenBSD rtsx PR204521 Henri Hennebert hlh@restart.be

The rtsx driver for Realtek SD card reader has been ported from OpenBSD. Its development snapshot is available via the sysutils/rtsx-kmod port.

From March to May 2020, the code has been completed with the help of Gary Jennejohn (gj@) and Jesper Schmitz Mouridsen (jsm@). Some tweaks have been imported from the Linux counterpart.

The driver has been successfully tested with:

The driver should also work for Realtek RTS5249, RTL8402 and RTL8411.

More tests are welcome, especially for the devices not yet tested. These devices may require more tweaks.

PR204521 contains the bulk of exchanges for completion of the code.

Valgrind updates Paul Floyd paulf@free.fr Kyle Evans kevans@FreeBSD.org Patch for valgrind

A large amount of work has been done to rebase FreeBSD support on top of Valgrind 3.17.0, and to address numerous test suite failures. Currently, almost all of the regression tests pass on amd64. This is a major improvement over the current state of affairs, in which the Valgrind is quite out of date and is missing important functionality. Some follow-up work aims to make FreeBSD an officially supported target platform for Valgrind.

The devel/valgrind-devel port is in the process of being updated to point at the new work.

chaifi - a tool to simplify joining public WiFi networks chaifi Oleksandr Tymoshenko gonzo@FreeBSD.org

chaifi is a TUI (text UI) utility aimed at simplifying the process of joining public WiFi networks in places like coffee shops or libraries. It replaces the process of scanning and manually editing wpa_supplicant.conf with an interactive dialog. The utility is in no way a replacement for full-featured network managers in major desktop environments. Still, if you're working from a console or using a tiling window manager, it may save you some seconds (or in worst case minutes) of your time.

MixerTUI mixertui Alfonso Sabato Siciliano alfonso.siciliano@email.com

MixerTUI is a volume mixer with a Terminal User Interface built on the FreeBSD sound system. It can show the current Sound Driver configuration and select an audio device: to get its information, to change the volume or to set it as default, the last feature allows to switch easily audio from/to laptop and hdmi, headphones and speakers, and so on.
MixerTUI can be installed via the audio/mixertui port.

I would like to thank the FreeBSD community for the tips, feedbacks and patches to improve this project.

Potluck - Flavour & Image Repository for pot Potluck Repository & Project Potluck on github pot project Stephan Lichtenauer sl@honeyguide.eu

pot is a jail management tool that also supports orchestration through nomad.

Potluck aims to be to FreeBSD and pot what Dockerhub is to Linux and Docker: A repository of pot flavours and complete images for usage with pot.

This should simplify setting up complex software with many packages and ports in comparison to manual configuration: Potluck aims to provide a content library as an additional layer of abstraction, on top of existing infrastructure like pkg, that pot has to offer.

Pot "flavour" files are provided on [Github]((https://github.com/hny-gd/potluck)) and fed into a Jenkins instance. On the Potluck Repository, for each flavour, detailed descriptions as well as ready-made images to be imported by pot are provided.

The initial project has been set up, and three simple flavours, along with a complete Jitsi Meet instance in a jail has been created as a Proof of Concept that should allow running a fully-fledged video conference system with just a few easy commands within a few minutes.

As only the initial versions have been set up and implemented so far, general feedback, tests, as well as additional, useful flavours are very welcome!

FreshPorts FreshPorts FreshPorts blog Dan Langille dan@langille.org

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

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

For example, https://www.freshports.org/security/acme.sh/ shows the history of this port, back to its creation in May 2017.

git

Work on git started back in September. It was ignored for a while and started back in mid-June with the creation of new git-specific jails for commit ingress (commit processing gitdev) and for the website.

Serhii (Sergey) Kozlov created a script to transform GIT commit entries into XML digestible by FreshPorts. This was a huge step foward for the effort.

The next step include:

Help wanted

git is not far away now. I could use helpers to

Thank you

Packages

FreshPorts now displays the packages version available from the repo sources. This covers all primary tiers (e.g. FreeBSD:12:amd64) and all secondary tiers (e.g. FreeBSD:13:powerpc64). This helps uses know what versions they can expect and when then repo was last built.

Dependency lines

Some things are easiest done via copy/paste. If you are working on a port Makefile and need to add a new dependency, FreshPorts shows the dependency line for that port. For example: 


 acme.sh>0:security/acme.sh

Libraries are also covered by this feature.

Python ports were recently adjusted to display 


  ${PYTHON_PKGNAMEPREFIX}virtualenv>0:devel/py-virtualenv

instead of 


 py37-virtualenv>0:devel/py-virtualenv

You can read more about this change in [issue #73](https://github.com/FreshPorts/freshports/issues/73).

Watch ports I maintain

The search page has long had the "Ports I Maintain" button (if you are logged in). This feature recently branched out to a new automated watch list option: Watch ports I maintain.

This report subscription will notify you of any commits to the ports you maintain. Your email address on FreshPorts must match the value in the MAINTAINER field of the port. This is always a daily report.

From time to time, an infrastructure change will occur which touches your port. This feature ensures you know about that change.

Repology links

Repology links were requested. This allows you to see what versions of that port are in the repositories of other systems. A link to repology.org appears on every port page.

Further reading

Based upon things you didn’t know FreshPorts can do

There are many things FreshPorts can do, including search Makefile's and pkg-plist. This is from a recent blog post:

Javascript help wanted

We recently upgraded some outdated Javascript modules. This broke our [JavaScript based graphs](https://www.freshports.org/graphs2.php). We could use some help on fixing that please. The starting points are listed on that URL. If you need a working website to play with, please contact me with a ssh public-key.

Sponsor: hardware provided by iXsystems

PCI passthrough with bhyve on Intel and for OpenBSD guests bhyve Intel bug report bhyve OpenBSD bug report PCI passthrough with bhyve (FreeBSD wiki article) Anatoli me@anatoli.ws Callum callum@aitchison.org Peter Grehan grehan@freebsd.org

bhyve(8) is a hypervisor that supports running a variety of guest operating systems in virtual machines. bhyve(8) includes support for PCI devices passthru, a technique to pass host PCI devices to a virtual machine for its exclusive control and use.

For some years, PCI passthrough (ppt) in bhyve was not working on some Intel systems and for OpenBSD guests due to two bugs. The first one was crashing FreeBSD host when bhyve was started with ppt on Intel processors with two VT-d translation units (IOMMU), included in most Skylake and newer Intel processors.

The second bug was preventing correct interrupts handling for OpenBSD guests. As a result, OpenBSD guests running on bhyve were not able to use any PCI devices passed through to them from the host.

During the last 2 months the second bug was identified and fixed and they both were backported to 12.1-RELEASE (p7). So now it's possible to fully take advantage of PCI passthrough (ppt) with bhyve in a production-ready RELEASE version.

The most typical case for ppt is to pass to the guest network adapters for its complete control, but you can also pass through USB devices (including external HDDs). Note though, passthrough of VGA and GPU devices is not supported yet (for more details see the 3rd link).

A particularly interesting case for ppt is to use OpenBSD guest as a firewall and a router for a FreeBSD server.

With ppt you can achieve this all inside a single server. You could pass to the OpenBSD guest a network adapter connected to the internet and it would take a complete control of it. After filtering the traffic, it could pass good packets via virtual network interfaces to other guests or to the host.

Once a network adapter is passed through, a FreeBSD host not only doesn't see it and hence doesn't handle the network traffic, it doesn't even have to initialize the adapter (e.g. in case of a WiFi card, it's the guest that loads the firmware).

In simple terms the host only passes the device interrupts to the guest as they come from the hardware. Everything related to the device management happens inside the guest so there's no danger that some network traffic exploits some issue in the host's network stack and causes the host to crash or misbehave in other ways.

SageMath SageMath site Thierry Thomas thierry@FreeBSD.org

SageMath is a free open-source mathematics software system licensed under the GPL. It builds on top of many existing open-source packages: NumPy, SciPy, matplotlib, Sympy, Maxima, GAP, FLINT, R and many more. Thanks to SageMath it is possible to access their combined power through a common, Python-based language or directly via interfaces or wrappers.

The goal is creating a viable free open source alternative to Magma, Maple, Mathematica and Matlab.

This is a complex port, with a lot of dependencies, and it has been broken for some time. Upstream is working on easing its packaging, and many previously bundled applications can now be replaced by external packages.

If you are interested, it would be nice to create a team of maintainers

team &os; Team Reports

Entries from the various official and semi-official teams, as found in the Administration Page.

 proj Projects

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

 kern Kernel

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

 arch Architectures

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

. bin Userland Programs

Changes affecting the base system and programs in it.

 ports Ports

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

 doc Documentation

Noteworthy changes in the documentation tree, in manpages, or in external books/documents.

 misc Miscellaneous

Objects that defy categorization.

 third Third-Party Projects

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