aboutsummaryrefslogtreecommitdiff
path: root/en_US.ISO8859-1/htdocs
diff options
context:
space:
mode:
authorEdward Tomasz Napierala <trasz@FreeBSD.org>2020-10-21 18:50:27 +0000
committerEdward Tomasz Napierala <trasz@FreeBSD.org>2020-10-21 18:50:27 +0000
commitaabf023eeffef6533e574caebbebbeee93f698dd (patch)
tree633be4e24f00a57f90fe61d727fbf8c401570108 /en_US.ISO8859-1/htdocs
parent3eebd779982776132f16bdb92ee45c8f114fe0b6 (diff)
downloaddoc-aabf023eeffef6533e574caebbebbeee93f698dd.tar.gz
doc-aabf023eeffef6533e574caebbebbeee93f698dd.zip
Create 2020q2 status report, covering June 2020 to September 2020.
Submitted by: debdrup Differential Revision: https://reviews.freebsd.org/D26890
Notes
Notes: svn path=/head/; revision=54617
Diffstat (limited to 'en_US.ISO8859-1/htdocs')
-rw-r--r--en_US.ISO8859-1/htdocs/news/status/Makefile1
-rw-r--r--en_US.ISO8859-1/htdocs/news/status/report-2020-07-2020-09.xml2172
2 files changed, 2173 insertions, 0 deletions
diff --git a/en_US.ISO8859-1/htdocs/news/status/Makefile b/en_US.ISO8859-1/htdocs/news/status/Makefile
index 878e9dc513..d44428f747 100644
--- a/en_US.ISO8859-1/htdocs/news/status/Makefile
+++ b/en_US.ISO8859-1/htdocs/news/status/Makefile
@@ -88,6 +88,7 @@ XMLDOCS+= report-2019-07-2019-09
XMLDOCS+= report-2019-10-2019-12
XMLDOCS+= report-2020-01-2020-03
XMLDOCS+= report-2020-04-2020-06
+XMLDOCS+= report-2020-07-2020-09
XSLT.DEFAULT= report.xsl
# Install a sample <project> entry.
diff --git a/en_US.ISO8859-1/htdocs/news/status/report-2020-07-2020-09.xml b/en_US.ISO8859-1/htdocs/news/status/report-2020-07-2020-09.xml
new file mode 100644
index 0000000000..380df5000d
--- /dev/null
+++ b/en_US.ISO8859-1/htdocs/news/status/report-2020-07-2020-09.xml
@@ -0,0 +1,2172 @@
+<?xml version="1.0" encoding="utf-8" ?>
+<!DOCTYPE report PUBLIC "-//FreeBSD//DTD FreeBSD XML Database for
+ Status Report//EN"
+ "http://www.FreeBSD.org/XML/share/xml/statusreport.dtd" >
+
+<!-- $FreeBSD$ -->
+
+<!--
+ Variables to replace:
+ 07 - report month start
+ 09 - report month end
+ 2020 - report year
+ %%NUM%% - report issue (first, second, third, fourth)
+ %%STARTNEXT%% - report month start
+ %%STOPNEXT%% - report month end
+ %%YEARNEXT%% - next report due year (if different than 2020)
+ %%DUENEXT%% - next report due date (i.e., June 6)
+-->
+
+<report>
+ <date>
+ <month>07-09</month>
+
+ <year>2020</year>
+ </date>
+
+ <section>
+ <title>Introduction</title>
+<p>This report covers FreeBSD related projects for the period between
+July and September, and is the third of four planned reports for 2020.
+</p>
+<p>This quarter brings a good mix of additions and changes to the FreeBSD
+Project and community, from a diverse number of teams and people covering
+everything from architectures, continuous integration, wireless networking
+and drivers, over drm, desktop and third-party project work, as well as
+several team reports, along with many other interesting subjects too
+numerous to mention.
+</p>
+<p>As the world is still affected by the epidemic, we hope that this report
+can also serve as a good reminder that there is good work that can be done
+by people working together, even if we're apart.
+</p>
+<p>We hope you'll be as interested in reading it, as we've been in making it.
+Daniel Ebdrup Jensen, on behalf of the quarterly team.
+</p> </section>
+<project cat='team'>
+<title>FreeBSD Foundation</title>
+
+<contact>
+<person>
+<name>Deb Goodkin</name>
+<email>deb@FreeBSDFoundation.org</email>
+</person>
+</contact>
+
+<body><p>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.
+</p>
+<p>Here are some highlights of what we did to help FreeBSD last quarter:
+</p>
+<h3>COVID-19 Impact to the Foundation</h3>
+
+<p>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.
+</p>
+<h3>Partnerships and Commercial User Support</h3>
+
+<p>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 Q3 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.
+</p>
+<p>We are currently scheduling Zoom company meetings for Q4, please reach out if
+you would like to schedule a meeting with us.
+</p>
+<h3>Fundraising Efforts</h3>
+
+<p>Last quarter we raised $192,874.43! Thank you to the individuals and
+organizations that stepped in, to help fund our efforts. We'd like to thank
+Arm for their large contribution last quarter, which helped bring our 2020
+fundraising effort to $521k. We hope other organizations will follow their
+lead and give back to help us continue supporting FreeBSD.
+</p>
+<p>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!
+</p>
+<p>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.
+</p>
+<p>Please consider making a
+<a href='https://www.FreeBSDfoundation.org/donate/.'>donation to help us continue and increase our support for FreeBSD</a>.
+</p>
+<p>We also have the Partnership Program, to provide more benefits for our larger
+commercial donors. Find out more information about the
+<a href='https://www.FreeBSDfoundation.org/FreeBSD-foundation-partnership-program/'>partnership program</a>
+and share with your companies!
+</p>
+<h3>OS Improvements</h3>
+
+<p>A number of FreeBSD Foundation grant recipients started, continued working on,
+or completed projects during the third quarter. These include:
+</p><ul>
+<li><p>Ongoing WiFi and Linux KPI layer improvements.
+</p></li>
+<li><p>Linuxulator application compatibility.
+</p></li>
+<li><p>DRM / Graphics driver updates.
+</p></li>
+<li><p>Zstd compression for OpenZFS.
+</p></li>
+<li><p>Online RAID-Z expansion.
+</p></li>
+<li><p>Modernized LLDB target support for FreeBSD.
+</p>
+</li></ul>
+You can find more details about most of these projects in other quarterly
+<p>reports.
+</p>
+<p>Staff members also worked on a number of larger projects, including:
+</p><ul>
+<li><p>Run-Time Dynamic Linker (rtld) and kernel ELF loader improvements.
+</p></li>
+<li><p>Rewritten UNIX domain socket locking.
+</p></li>
+<li><p>Build infrastructure.
+</p></li>
+<li><p>Open system call path handling support for O_BENEATH, O_RESOLVE_BENEATH.
+</p></li>
+<li><p>arm64 support.
+</p></li>
+<li><p>Migration to a Git repository.
+</p>
+</li></ul>
+Many of these projects also have detailed entries in other quarterly report
+<p>entries.
+</p>
+<p>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.
+</p>
+<h3>University of Waterloo Co-op</h3>
+
+<p>With the transition to working from home, the Foundation decided to again take
+on three University of Waterloo Co-op students for the Fall 2020 term
+(September to December). Tiger returns for a second term, joined by new
+students Yang and Zac. Projects for the term include more work on
+ELF Tool Chain, application of Capsicum to additional utilities, testing and
+integration of FreePBX and Asterisk VOIP software, pkgbase, and exploring
+containerization tooling.
+</p>
+<h3>Continuous Integration and Quality Assurance</h3>
+
+<p>The Foundation provides a full-time staff member and funds projects on
+improving continuous integration, automated testing, and overall quality
+assurance efforts for the FreeBSD project.
+</p>
+<p>During the third quarter of 2020, Foundation staff continued improving and
+monitoring the Project's CI infrastructure, and working with experts to fix
+the failing builds and the regressions found by tests. The setting up of
+dedicated VM host for running tests is completed. New feature developments
+and the CI staging environment is in progress. We are also working with
+other teams in the Project for their testing needs. For example, tests of
+non-x86 architectures now run periodically, and improve the CI of the
+embedded systems. We are also working with many external projects and
+companies to improve the CI between their products and FreeBSD.
+</p>
+<p>See the FreeBSD CI section of this report for completed work items and detailed
+information.
+</p>
+<h3>Supporting FreeBSD Infrastructure</h3>
+
+<p>The Foundation provides hardware and support to improve the FreeBSD
+infrastructure. Last quarter, we continued supporting FreeBSD hardware located
+around the world. We coordinated efforts between the new NYI Chicago facility
+and clusteradm to start working on getting the facility prepared for some of
+the new FreeBSD hardware we are planning on purchasing. NYI generously
+provides this for free to the Project. We also worked on connecting with the
+new owners of the Bridgewater site, where most of the FreeBSD infrastructure is
+located.
+</p>
+<p>Some of the purchases we made for the Project last quarter to support
+infrastructure includes:
+</p><ul>
+<li><p>Spamhaus spam filtering software to limit the amount of spam on the mailing
+ lists.
+</p></li>
+<li><p>5 application servers to run tasks like bugzilla, wiki, website, cgi,
+ Phabricator, host git, etc.
+</p></li>
+<li><p>1 server to replace the old pkg server and provide a lot more IOPS to
+ avoid the slowdowns seen during peak times of the day where the disks just
+ cannot keep up with the request volume.
+</p></li>
+<li><p>1 server for exp-runs to make them faster.
+</p></li>
+<li><p>1 server to build packages more frequently.
+</p>
+</li></ul>
+<h3>FreeBSD Advocacy and Education</h3>
+
+<p>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.
+</p>
+<p>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.
+</p>
+<p>Check out some of the advocacy and education work we did last quarter:
+</p><ul>
+<li><p>Launched our FreeBSD Fridays series of 101 classes. Topics included an
+ Introduction to FreeBSD, FreeBSD Installfest, Introduction to Security,
+ Introduction to ZFS and more. Videos of the past sessions and a schedule of
+ upcoming events can be found <a href='https://freebsdfoundation.org/freebsd-fridays/'>here</a>.
+</p></li>
+<li><p>Attended and presented at OSI's State of the Source conference. The event
+ was held virtually, September 9-11, 2020.
+</p></li>
+<li><p>Launched the
+ <a href='https://freebsdfoundation.org/blog/weve-got-a-new-look/'>redesign</a>
+ of the FreeBSD Foundation Website.
+</p></li>
+<li><p><a href='https://freebsdfoundation.org/news-and-events/latest-news/freebsd-foundation-celebrates-20th-anniversary/'>Announced</a>
+ the 20th Anniversary of the FreeBSD Foundation.
+</p></li>
+<li><p>Participated as an Admin for Google Summer of Code 2020
+</p></li>
+<li><p>Continued to promote the FreeBSD Office Hours series including holding our
+ own Foundation led office hours. Videos from the one hour sessions can be
+ found on the Project's
+ <a href='https://www.youtube.com/c/FreeBSDProject'>YouTube Channel</a>. You can watch
+ ours <a href='https://www.youtube.com/watch?v=Ji4ux4FWpRU'>here</a>.
+</p></li>
+<li><p><a href='https://freebsdfoundation.org/blog/freebsd-core-team-10-in-review/'>Interviewed</a>
+ members of the outgoing FreeBSD Core Team to get their thoughts on their
+ term.
+</p></li>
+<li><p>Began working with the FreeBSD Vendor Summit planning committee on the
+ <a href='https://wiki.freebsd.org/DevSummit/202011'>November 2020 Vendor Summit</a>.
+</p></li>
+<li><p>Promoted the Foundation's 20th Anniversary and our work to support the
+ FreeBSD Project in the It's FOSS Article.
+ <a href='https://itsfoss.com/freebsd-foundation-20-years/'>FreeBSD Foundation Celebrates 20 Years of Promoting and Supporting FreeBSD Project</a>.
+</p></li>
+<li><p>Authored a <a href='https://www.fosslife.org/beginners-guide-freebsd'>Beginners Guide to FreeBSD</a> for Fosslife.
+</p></li>
+<li><p>Committed to sponsoring All Things Open as a media Sponsor.
+</p></li>
+<li><p>Committed to sponsoring the OpenZFS Developers Summit at the Bronze level.
+</p></li>
+<li><p>Became an International RISC-V Member.
+</p></li>
+<li><p>Committed to giving a FreeBSD talk at the nerdear.la conference on
+ October 20th.
+</p>
+</li></ul>
+Keep up to date with our latest work in our
+<p><a href='https://www.freebsdfoundation.org/news-and-events/newsletter/'>monthly newsletters</a>.
+</p>
+<p>Netflix provided an update on how and why they use FreeBSD in our latest
+<a href='https://freebsdfoundation.org/wp-content/uploads/2020/10/netflixcasestudy_final.pdf'>Contributor Case Study</a>.
+</p>
+<p>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 at
+https://www.FreeBSDfoundation.org/journal/.
+</p>
+<p>You can find out more about events we attended and upcoming events at
+https://www.FreeBSDfoundation.org/news-and-events/.
+</p>
+<h3>Legal/FreeBSD IP</h3>
+
+<p>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. We updated our
+<a href='https://freebsdfoundation.org/legal/trademark-usage-terms-and-conditions/'>Trademark Usage Terms and Conditions</a>
+on July 1, 2020.
+</p>
+<p>Go to <a href='http://www.FreeBSDfoundation.org/'>the FreeBSD Foundation's web site</a> to
+find out how we support FreeBSD and how we can help you!
+</p>
+<p>### Other
+</p>
+<p>We welcomed Andrew Wafaa and Kevin Bowling to our board of directors, to help
+govern the Foundation and guide us with our strategic direction. We have
+<a href='https://freebsdfoundation.org/blog/freebsd-foundation-welcomes-new-board-members-2/'>more information about our new board members</a>
+on our website.
+</p></body></project>
+<project cat='team'>
+<title>FreeBSD Release Engineering Team</title>
+
+<contact>
+<person>
+<name>FreeBSD Release Engineering Team</name>
+<email>re@FreeBSD.org</email>
+</person>
+</contact>
+
+<links>
+<url href='https://www.freebsd.org/releases/12.2R/schedule.html'>FreeBSD 12.2-RELEASE schedule</url>
+<url href='https://www.freebsd.org/where.html#helptest'>FreeBSD 12.2 test builds</url>
+<url href='https://download.freebsd.org/ftp/snapshots/ISO-IMAGES/'>FreeBSD development snapshots</url>
+</links>
+
+<body><p>The FreeBSD Release Engineering Team is responsible for setting
+and publishing release schedules for official project releases
+of FreeBSD, announcing code freezes and maintaining the respective
+branches, among other things.
+</p>
+<p>During the third quarter of 2020, the Release Engineering Team started
+work on the 12.2-RELEASE cycle, the third release from the stable/12
+branch.
+</p>
+<p>As of this writing, two BETA builds have been released, with the
+expectation there will be a third BETA build currently remaining on the
+schedule.
+</p>
+<p>The 12.2-RELEASE cycle will continue throughout October, with two RC
+builds currently planned, and RC3 scheduled on an as-needed basis. The
+12.2-RELEASE is so far scheduled for final release on October 27.
+</p>
+<p>In addition to the 12.2-RELEASE, Glen Barber of the Release Engineering
+Team finished work to the release build tools and scripts to prepare for
+the conversion from Subversion to Git for the 13.0-RELEASE cycle. There
+are no plans to merge these changes to stable branches at this time; as
+discussed within the Git working group, we feel such a change on a stable
+branch would be too intrusive to our user base as well as downstream
+FreeBSD consumers. Development snapshot builds for 13.0-CURRENT have
+recently been built from the Git tree within the project, and further
+snapshot builds for 12.x and 11.x will continue to be built from Subversion.
+</p>
+<p>Additionally throughout the quarter, several development snapshots builds
+were released for the <i>head</i>, <i>stable/12</i>, and <i>stable/11</i> branches.
+</p>
+<p>Finally, the Release Engineering Team would like to thank Marius Strobl
+for his time serving on the team; he had recently stepped down from the
+Deputy RE Lead role due to constraints on his time. The Team welcomes
+Colin Percival, who has accepted fulfilling this role.
+</p>
+<p>Much of this work was sponsored by Rubicon Communications, LLC (netgate.com)
+and the FreeBSD Foundation.
+</p></body></project>
+<project cat='team'>
+<title>Cluster Administration Team</title>
+
+<contact>
+<person>
+<name>Cluster Administration Team</name>
+<email>clusteradm@FreeBSD.org</email>
+</person>
+</contact>
+
+<links>
+<url href='https://www.freebsd.org/administration.html#t-clusteradm'>Cluster Administration Team members</url>
+</links>
+
+<body><p>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:
+</p><ul>
+<li><p>Work with the FreeBSD Foundation on hardware update for web services, mirror and package building servers.
+</p></li>
+<li><p>Disable directory indexing on the package mirrors to resolve performance issues of the machine.
+</p><ul>
+<li><p>This was later relaxed to allow indexing of the parent directories but still disallow the large package directories.
+</p></li></ul>
+</li><li><p>Ongoing systems administration work:
+</p><ul>
+<li><p>Accounts management for committers.
+</p></li>
+<li><p>Backups of critical infrastructure.
+</p></li>
+<li><p>Keeping up with security updates in 3rd party software.
+</p>
+</li></ul>
+</li></ul>
+Work in progress:
+
+<ul>
+<li><p>Setup Malaysia (KUL) mirror.
+</p></li>
+<li><p>Setup Brazil (BRA) mirror.
+</p></li>
+<li><p>Review the service jails and service administrators operation.
+</p></li>
+<li><p>Infrastructure of building aarch64 and powerpc64 packages.
+</p><ul>
+<li><p>NVMe issues on PowerPC64 POWER9 blocking dual socket machine from being used as pkg builder.
+</p></li>
+<li><p>Drive upgrade test for pkg builders (SSDs) courtesy of the FreeBSD Foundation.
+</p></li>
+<li><p>Boot issues with Aarch64 reference machines.
+</p></li></ul>
+</li><li><p>New NYI.net sponsored colocation space in Chicago-land area.
+</p></li>
+<li><p>Work with git working group for the git repository.
+</p></li>
+<li><p>Searching for more providers that can fit the requirements for a <a href='https://wiki.freebsd.org/Teams/clusteradm/generic-mirror-layout'>generic mirrored layout</a> or a <a href='https://wiki.freebsd.org/Teams/clusteradm/tiny-mirror'>tiny mirror</a>.
+</p></li></ul>
+</body></project>
+<project cat='team'>
+<title>Continuous Integration</title>
+
+<links>
+<url href='https://ci.FreeBSD.org'>FreeBSD Jenkins Instance</url>
+<url href='https://ci.FreeBSD.org/hwlab'>FreeBSD Hardware Testing Lab</url>
+<url href='https://artifact.ci.FreeBSD.org'>FreeBSD CI artifact archive</url>
+<url href='https://hackmd.io/@FreeBSD-CI'>FreeBSD CI weekly report</url>
+<url href='https://wiki.freebsd.org/Jenkins'>FreeBSD Jenkins wiki</url>
+<url href='https://wiki.freebsd.org/HostedCI'>Hosted CI wiki</url>
+<url href='https://wiki.freebsd.org/3rdPartySoftwareCI'>3rd Party Software CI</url>
+<url href='https://preview.tinyurl.com/y9maauwg'>Tickets related to freebsd-testing@</url>
+<url href='https://github.com/freebsd/freebsd-ci'>FreeBSD CI Repository</url>
+</links>
+
+<contact>
+<person>
+<name>Jenkins Admin</name>
+<email>jenkins-admin@FreeBSD.org</email>
+</person>
+<person>
+<name>Li-Wen Hsu</name>
+<email>lwhsu@FreeBSD.org</email>
+</person>
+</contact>
+<body><p>Contact: <a href='https://lists.FreeBSD.org/mailman/listinfo/freebsd-testing'>freebsd-testing Mailing List</a><br />
+Contact: IRC #freebsd-ci channel on EFNet<br />
+</p>
+<p>The FreeBSD CI team maintains the continuous integration system
+of 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 those builds 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
+are available in the <a href='https://hackmd.io/@FreeBSD-CI'>weekly CI reports</a>.
+</p>
+<p>During the third quarter of 2020, we continued working with the contributors and
+developers in the project to fulfill their testing needs and also keep
+collaborating with external projects and companies to improve their products
+and FreeBSD.
+</p>
+<p>Important changes:
+</p><ul>
+<li><p>All !x86 -test builds now trigger a new build on 22:00 UTC daily; this was
+ not running very often because running all the tests in qemu takes lots
+ of time. The work on improving the test execution speed and parallelism is
+ in progress. The following is a list of the jobs affected:
+</p><ul>
+<li><p><a href='https://ci.freebsd.org/job/FreeBSD-head-armv7-test/'>Test build for FreeBSD HEAD on ARMv7</a>.
+</p></li>
+<li><p><a href='https://ci.freebsd.org/job/FreeBSD-head-aarch64-test/'>Test build for FreeBSD HEAD on AArch64</a>.
+</p></li>
+<li><p><a href='https://ci.freebsd.org/job/FreeBSD-head-mips64-test/'>Test build for FreeBSD HEAD on MIPS64</a>.
+</p></li>
+<li><p><a href='https://ci.freebsd.org/job/FreeBSD-head-powerpc64-test/'>Test build for FreeBSD HEAD on PowerPC64</a>.
+</p></li>
+<li><p><a href='https://ci.freebsd.org/job/FreeBSD-head-riscv64-test/'>Test build for FreeBSD HEAD on RISC-V64</a>.
+</p>
+</li></ul>
+</li><li><p>The build and test results will be sent to the
+ <a href='https://lists.freebsd.org/mailman/listinfo/dev-ci'>dev-ci mailing list</a>
+ soon. Feedback and help with analysis is very appreciated!
+</p>
+<ul>
+<li><p>A builder dedicated to run jobs using provisioned VMs is setup, this
+ improves the stableness and reduces the execution time.
+</p>
+</li>
+<li><p>The result of <a href='https://ci.freebsd.org/job/FreeBSD-head-amd64-test_zfs'>FreeBSD-head-amd64-test_zfs</a>
+ is changed after OpenZFS importing; we encourage everyone to check and fix the
+ failing and skipped test cases.
+</p>
+</li></ul>
+</li></ul>
+New jobs added:
+<ul>
+<li><p><a href='https://ci.freebsd.org/job/FreeBSD-head-powerpc64le-build/'>CI build for FreeBSD HEAD on PowerPC64LE</a>.
+</p>
+</li></ul>
+Work in progress:
+<ul>
+<li><p>Collecting and sorting CI tasks and ideas
+ <a href='https://hackmd.io/@FreeBSD-CI/freebsd-ci-todo'>here</a>.
+</p></li>
+<li><p>Testing and merging pull requests in the
+ <a href='https://github.com/freebsd/freebsd-ci/pulls'>the FreeBSD-ci repo</a>.
+</p></li>
+<li><p>Designing and implementing pre-commit CI building and testing,
+</p></li>
+<li><p>Reduce the procedures of CI/test environment setting up for contributors and
+ developers.
+</p></li>
+<li><p>Setting up the CI stage environment and putting the experimental jobs on it.
+</p></li>
+<li><p>Setting up public network access for the VM guest running tests.
+</p></li>
+<li><p>Implementing automatic tests on bare metal hardware.
+</p></li>
+<li><p>Adding drm ports building tests against -CURRENT.
+</p></li>
+<li><p>Planning to run ztest and network stack tests.
+</p></li>
+<li><p>Adding more external toolchain related jobs.
+</p></li>
+<li><p>Improving the hardware lab to be more mature and adding more hardware.
+</p></li>
+<li><p>Helping more 3rd software get CI on FreeBSD through a hosted CI solution.
+</p></li>
+<li><p>Working with hosted CI providers to have better FreeBSD support.
+</p>
+</li></ul>
+Please see freebsd-testing@ related tickets for more WIP information, and don't hesitate to join the effort!
+
+<p>Sponsor: The FreeBSD Foundation
+</p></body></project>
+<project cat='team'>
+<title>Ports Collection</title>
+
+<links>
+<url href='https://www.FreeBSD.org/ports/'>About FreeBSD Ports</url>
+<url href='https://www.freebsd.org/doc/en_US.ISO8859-1/articles/contributing/ports-contributing.html'>Contributing to Ports</url>
+<url href='http://portsmon.freebsd.org/index.html'>FreeBSD Ports Monitoring</url>
+<url href='https://www.freebsd.org/portmgr/index.html'>Ports Management Team</url>
+</links>
+
+<contact>
+<person>
+<name>René Ladan</name>
+<email>portmgr-secretary@FreeBSD.org</email>
+</person>
+<person>
+<name>FreeBSD Ports Management Team</name>
+<email>portmgr@FreeBSD.org</email>
+</person>
+</contact>
+
+<body><p>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.
+</p>
+<p>We passed the landmark of 40,000 ports in the Ports Collection
+and are now around 40,400 ports. The last quarter saw 9335
+commits to the HEAD branch and 481 commits to the 2020Q3 branch
+by respectively 167 and 63 committers. There are currently 2525
+open problem reports of which 595 are unassigned. Compared to
+last quarter, this means a slight decrease in activity and also
+a slight increase in open PRs.
+</p>
+<p>During the last quarter we welcomed Rainer Hurling (rhurlin@) and
+said goodbye to Kevin Lo (kevlo@) and Grzegorz Blach (gblach@).
+</p>
+<p>The last three months saw new default versions for Perl (5.32),
+PostgreSQL (12) and PHP (7.4). Various packages also got updated:
+Firefox to 81.0.1, Chromium to 84.0.4147.135, Gnome to 3.36,
+Xorg to 1.20.9, Qt5 to 5.15.0, Emacs to 27.1, KDE Frameworks to
+5.74.0 and pkg itself to 1.15.8.
+</p>
+<p>Never tired, antoine@ ran 30 exp-runs to test port version updates,
+on such diverse matters as:
+</p><ul>
+<li><p>Updating byacc in base to 20200330.
+</p></li>
+<li><p>Check balancing of sed "y" command.
+</p></li>
+<li><p>Use of brackets.
+</p></li>
+<li><p>Removing the now redundant "port" argument from USES=readline.
+</p></li></ul>
+</body></project>
+<project cat='team'>
+<title>FreeBSD Office team - 3rd quarter 2020 report</title>
+
+<links>
+<url href='https://wiki.freebsd.org/Office'>The FreeBSD Office project</url>
+</links>
+
+<contact>
+<person>
+<name>FreeBSD Office team ML</name>
+<email>office@FreeBSD.org</email>
+</person>
+<person>
+<name>Dima Panov</name>
+<email>fluffy@FreeBSD.org</email>
+</person>
+<person>
+<name>Li-Wen Hsu</name>
+<email>lwhsu@FreeBSD.org</email>
+</person>
+</contact>
+
+
+<body><p>The FreeBSD Office team works on a number of office-related software suites
+and tools such as OpenOffice and LibreOffice.<br />
+</p>
+<p>Work during this quarter focused on providing the latest stable release of
+LibreOffice suite and companion apps to all FreeBSD users.
+</p>
+<ul>
+<li><p>Alongside with updating old stable branch to latest 6.4.x releases,
+ current ports-tree now have a full-featured cutting-edge 7.0.1 bundle.<br />
+</p></li>
+<li><p>Conservative users can keep 6.4.x stable version by switching to use
+ all-in-one editors/libreoffice6 port and even with i18n language pack (off by default).
+ It will be kept updated at least till 7.1.0 version is released.<br />
+</p>
+</li></ul>
+We are looking for people to help the project.
+<p>All unstable work with LibreOffice snapshots is staged in our <a href='https://github.com/lwhsu/freebsd-ports-libreoffice'>WIP repository</a>.<br />
+The <a href='https://bugs.freebsd.org/bugzilla/buglist.cgi?bug_status=open&amp;email1=office%40FreeBSD.org&amp;emailassigned_to1=1&amp;emailcc1=1&amp;emailreporter1=1&amp;emailtype1=substring&amp;query_format=advanced&amp;list_id=374316'>open bugs list</a>
+contains all filed issues which need some attention.
+Patches, comments and objections are always welcome in the mailing list and bugzilla.
+</p>
+</body></project>
+<project cat='team'>
+<title>FreeBSD Graphics Team status report</title>
+
+<links>
+<url href='https://github.com/FreeBSDDesktop'>Project GitHub page</url>
+</links>
+
+<contact>
+<person>
+<name>FreeBSD Graphics Team</name>
+<email>x11@freebsd.org</email>
+</person>
+<person>
+<name>Niclas Zeising</name>
+<email>zeising@freebsd.org</email>
+</person>
+</contact>
+
+<body><p>The FreeBSD X11/Graphics team maintains the lower levels of the FreeBSD graphics
+stack.
+This includes graphics drivers, graphics libraries such as the
+MESA OpenGL implementation, the X.org xserver with related libraries and
+applications, and Wayland with related libraries and applications.
+</p>
+<p>There have been several updates to the FreeBSD graphics stack and related
+libraries since the last report.
+</p>
+<p>Most notably, MESA related ports were changed to use the meson build system,
+instead of the autotools based one.
+This was needed since mesa upstream has deprecated and removed the autotools
+build system, and this paved the way for further mesa updates.
+While there was a need for a few minor corrections after the initial update,
+this update has been successful and made it possible to further update and
+improve the FreeBSD mesa port.
+</p>
+<p>There have also been several security fixes for <code>xorg-server</code> and <code>libX11</code>, so
+these ports have been updated to fix these issues.
+</p>
+<p>During the period, FreeBSD 12 was changed to improve the compatibility with
+input devices using udev/evdev and libinput.
+This change removes the need for local configuration and makes most mice,
+touchpads and keyboards work out of the box.
+This change will be in the upcoming FreeBSD 12.2 release.
+</p>
+<p>There have also been several updates to various libraries, both in the graphics
+and input stacks, and several userland drivers have been updated.
+Libraries such as <code>libdrm</code> and <code>libevdev</code> have been updated to include new
+FreeBSD support, developed by team members and added upstream.
+</p>
+<p>There has also been ongoing work to keep the various drm-kmod ports and packages
+up to date, mostly in response to changes in various FreeBSD versions.
+</p>
+<p>We have also continued our regularly scheduled bi-weekly meetings.
+</p>
+<p>People who are interested in helping out can find us on the x11@FreeBSD.org
+mailing list, or on our <a href='https://gitter.im/FreeBSDDesktop/Lobby'>gitter chat</a>.
+We are also available in #freebsd-xorg on EFNet.
+</p>
+<p>We also have a team area <a href='https://github.com/FreeBSDDesktop'>on GitHub</a> where our work repositories can be found.
+</p></body></project>
+<project cat='proj'>
+<title>FreeBSD on Microsoft HyperV and Azure</title>
+
+<links>
+<url href='https://wiki.freebsd.org/MicrosoftAzure'>Microsoft Azure article on FreeBSD wiki</url>
+<url href='https://wiki.freebsd.org/HyperV'>Microsoft HyperV article on FreeBSD wiki</url>
+</links>
+
+<contact>
+<person>
+<name>FreeBSD Integration Services Team</name>
+<email>bsdic@microsoft.com</email>
+</person>
+<person>
+<name>Wei Hu</name>
+<email>whu@FreeBSD.org</email>
+</person>
+<person>
+<name>Li-Wen Hsu</name>
+<email>lwhsu@FreeBSD.org</email>
+</person>
+</contact>
+
+<body><p>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 <a href='https://reviews.freebsd.org/D23804'>here</a>.
+The <a href='https://azuremarketplace.microsoft.com/marketplace/apps/thefreebsdfoundation.freebsd-11_4'>11.4-RELEASE image on Azure Marketplace</a> is published.
+We are testing the releng/12.2 branch and 12.2-RELEASE image will be
+published to Azure Marketplace soon after released.
+</p>
+<p>This project is sponsored by The FreeBSD Foundation, with resources provided by Microsoft.
+</p></body></project>
+<project cat='proj'>
+<title>Building FreeBSD on non-FreeBSD hosts</title>
+
+<links>
+<url href='https://wiki.freebsd.org/BuildingOnNonFreeBSD'>Wiki</url>
+</links>
+
+<contact>
+<person>
+<name>Alex Richardson</name>
+<email>arichardson@freebsd.org</email>
+</person>
+</contact>
+
+<body><p>Until recently FreeBSD could only be built on a FreeBSD host.
+However, many popular free CI tools only allow building on Linux or macOS and
+therefore can not be used for building the FreeBSD base system. Furthermore, it
+is sometimes useful to cross-build FreeBSD for a remote machine or an emulator
+even if the build machine is not running FreeBSD.
+The goal of this project is to allow building the base system on Linux and macOS
+hosts.
+</p>
+<p>I started this project in 2017 to allow building <a href='https://github.com/CTSRD-CHERI/cheribsd'>CheriBSD</a> on the Linux servers
+and desktops that many of us working on the <a href='http://www.cheri-cpu.org'>CHERI project</a> use.
+The first few patches were upstreamed in 2018 (see the 2018q3 report) and
+I merged the full set of patches to CheriBSD shortly after. Over the past two
+years I have slowly been upstreaming the remaining patches and finally committed
+the last required change in time for this report.
+</p>
+<p>As of September 2020 it should be possible to use the <code>buildworld</code> and
+<code>buildkernel</code> make targets to build a fully-functional FreeBSD installation
+on macOS and Linux hosts. We use this in our continuous integration system to
+build and test CheriBSD disk images for multiple architectures.
+I have also committed a <a href='https://github.com/features/actions'>GitHub Actions</a> configuration upstream
+that takes approximately 10 minutes to build an amd64 kernel.
+This will ensure that changes that break crossbuilding from Linux/macOS
+can be detected easily.
+</p>
+<p>Upstreaming the crossbuilding changes has resulted in various build system
+cleanups. For example, we now <a href='https://reviews.freebsd.org/rS365836'>no longer need to use lorder.sh</a>
+when building libraries which speeds up the linking step a bit.
+The portability and bootstrapping changes should also make it easier
+to upgrade from older versions since we no longer rely on host headers in
+<code>/usr/include</code> matching those of the target system (e.g. when bootstrapping
+localedef, etc.).
+</p>
+<p>While this support for building on Linux and macOS should still be considered
+experimental, it should work in many cases. If you would like to give it a try,
+the following command line should successfully build an amd64 world on Linux
+and macOS systems that have packages for LLVM 10 (or newer) installed:
+<code>MAKEOBJDIRPREFIX=/somewhere ./tools/build/make.py TARGET=amd64 TARGET_ARCH=amd64 buildworld</code>
+Builds must be performed using the <code>./tools/build/make.py</code> wrapper script since
+most Linux and macOS systems do not ship an appropriate version of bmake.
+Please let me know if you encounter any issues.
+</p>
+<p>Sponsor: DARPA
+</p></body></project>
+<project cat='proj'>
+<title>Git Migration Working Group</title>
+
+<links>
+<url href='https://github.com/freebsd/git_conv'>Git conversion tooling repo</url>
+<url href='https://lists.freebsd.org/mailman/listinfo/freebsd-git'>FreeBSD-git mailing list</url>
+<url href='https://cgit-beta.FreeBSD.org/doc'>Beta doc git repo</url>
+<url href='https://cgit-beta.FreeBSD.org/ports'>Beta ports git repo</url>
+<url href='https://cgit-beta.FreeBSD.org/src'>Beta src git repo</url>
+</links>
+
+<contact>
+<person>
+<name>Ed Maste</name>
+<email>emaste@FreeBSD.org</email>
+</person>
+<person>
+<name>Warner Losh</name>
+<email>imp@FreeBSD.org</email>
+</person>
+<person>
+<name>Ulrich Spörlein</name>
+<email>uqs@FreeBSD.org</email>
+</person>
+</contact>
+
+<body><p>Work continues on FreeBSD's migration from Subversion to Git. Ulrich has
+addressed all known issues with svn2git and has been able to work around the
+inconsistent metadata and forced commit issues in the Subversion history.
+</p>
+<p>We still have additional documentation to write, and need to finish installing
+commit hooks (e.g. restricting branch creation, or ensuring appropriate data
+exists on cherry-pick commits).
+</p>
+<p>We expect to open the beta repository to test commits before the end of
+October. This is to allow testing of the commit hooks, and to allow developers
+to test access and become familiar with git operation. Commits in this
+repository will be deleted and the repository will be recreated at least once
+prior to the final migration.
+</p>
+<p>Those with an interest in the migration to Git are encouraged to subscribe
+to the
+<a href='https://lists.freebsd.org/mailman/listinfo/freebsd-git'>FreeBSD-git mailing list</a>
+and test out the beta src, ports, and/or doc repositories.
+</p>
+<p>You are also welcome check out the wiki, issues, README and other documentation
+at the <a href='https://github.com/freebsd/git_conv'>Git conversion tooling repo</a>.
+</p>
+<p>We currently expect to transition the src and doc repositories in mid-November.
+Additional investigation and experimentation with the ports repository is still
+underway.
+</p>
+<p>Sponsor: The FreeBSD Foundation (in part)
+</p></body></project>
+<project cat='proj'>
+<title>Linux compatibility layer update</title>
+
+<contact>
+<person>
+<name>Edward Tomasz Napierala</name>
+<email>trasz@FreeBSD.org</email>
+</person>
+<person>
+<name>Mark Johnston</name>
+<email>markj@FreeBSD.org</email>
+</person>
+</contact>
+
+<body><p>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 <a href='https://wiki.freebsd.org/LinuxApps'>Linux app status Wiki page</a>.
+Initial focus was 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.
+</p>
+<p>Foundation-sponsored work during this quarter included implementing
+a devfs(5) workaround to fix gettynam(3) inside jail/chroot, and
+workaround for the missing splice(2) syscall, which caused problems
+for grep and autotools. The Linux version reported to userspace was bumped
+to 3.10.0, which matches the kernel shipped with RHEL 7 and is neccessary
+for IBM's DB2 database installation to succeed. The BLKPBSZGET ioctl neccessary for
+Oracle database is supported now. There is now support for kcov(4),
+neccessary for syzcaller; as well as a number of fixes for issues
+reported by syzcaller, such as futex lock leaks.
+There were also more cleanups, including moving
+some Linuxulator-specific functionality related to error handling off
+from the syscall's fast code paths. The sysutils/debootstrap port,
+which provides an easy way to create Debian or Ubuntu jail, was updated
+to version 1.0.123. Finally there were some improvements
+to the <a href='https://wiki.freebsd.org/LinuxJails'>documentation</a>.
+</p>
+<p>Most of those changes have been merged to FreeBSD 12-STABLE, in order
+to ship with 12.2-RELEASE.
+</p>
+<p>There is increased involvement from other developers; this includes termios
+performance fixes, improved memfd support, implementing <code>CLOCK_MONOTONIC_RAW</code>
+required for Steam, madvise improvements, new <code>compat.linux.use_emul_path</code>
+sysctl. There is also ongoing work
+on tracking down the causes of failures related to Steam and WebKit, with
+fixes being first implemented in <a href='https://github.com/shkhln/linuxulator-steam-utils/wiki/Compatibility'>linuxulator-steam-utils</a>.
+</p>
+<p>Sponsor: The FreeBSD Foundation
+</p></body></project>
+<project cat='proj'>
+<title>LLDB Debugger Improvements</title>
+
+<links>
+<url href='https://www.moritz.systems/blog/lldb-debugger-improvements-for-freebsd/'>Moritz Systems Project Description</url>
+<url href='https://github.com/moritz-systems/llvm-project'>Git Repository</url>
+</links>
+
+<contact>
+<person>
+<name>Kamil Rytarowski</name>
+<email>kamil@moritz.systems</email>
+</person>
+<person>
+<name>Michał Górny</name>
+<email>mgorny@moritz.systems</email>
+</person>
+</contact>
+
+<body><p>FreeBSD includes LLDB, the debugger in the LLVM family, in the base
+system. At present it has some limitations in comparison with the GNU
+GDB debugger, and does not yet provide a complete replacement. It
+relies on an obsolete plugin model in LLDB that causes growing
+technical debt. This project aims to bring LLDB closer to a fully
+featured replacement for GDB, and therefore for FreeBSD to feature a
+modern debugger for software developers.
+</p>
+<p>The legacy monolithic target supports the executed application being
+debugged in the same process space as the debugger. The modern LLDB
+plugin approach, used on other supported targets, executes the
+target process under a separate lldb-server process. This improves
+reliability and simplifies the process / thread model in LLDB itself.
+In addition, remote and local debugging will both be performed using
+the same approach.
+</p>
+<p>After the migration to the new process model is complete, the project
+will include reviewing the results of LLDB's test suite and fixing
+tests as time permits. The work is expected to be complete in 2020.
+</p>
+<p>The project schedule is divided into three milestones, each taking approximately
+one month:
+</p>
+<p> 1. Introduce new FreeBSD Remote Process Plugin for x86_64 with basic support and upstream to LLVM.
+ 2. Ensure and add the mandated features in the project (process launch, process attach (pid), process attach (name), userland core files, breakpoints, watchpoints, threads, remote debugging) for FreeBSD/amd64 and FreeBSD/i386.
+ 3. Iterate over the LLDB tests. Detect, and as time permits, fix bugs. Ensure bug reports for each non-fixed and known problem. Add missing man pages and update the FreeBSD Handbook.
+</p>
+<p>We are nearing the completion of the first milestone. The new plugin is getting into
+shape, and it can already run simple single-threaded programs. The supported features
+include single-stepping, breakpoints, memory and register I/O on amd64.
+Both plugins are supported simultaneously. The new plugin is used if
+FREEBSD_REMOTE_PLUGIN environment variable is set to any value, or if lldb-server is
+spawned directly. Otherwise, the old plugin is used for compatibility. Once the new
+plugin matures, we are planning to enable it unconditionally on the architectures that
+it is ported to.
+</p>
+<p>Sponsor: The FreeBSD Foundation<br />
+</p></body></project>
+<project cat='proj'>
+<title>Lua usage in FreeBSD</title>
+
+<contact>
+<person>
+<name>Ed Maste</name>
+<email>emaste@FreeBSD.org</email>
+</person>
+<person>
+<name>Kyle Evans</name>
+<email>kevans@FreeBSD.org</email>
+</person>
+<person>
+<name>Ryan Moeller</name>
+<email>freqlabs@FreeBSD.org</email>
+</person>
+</contact>
+
+<body><p>During this quarter, flua (FreeBSD Lua) <a href='https://svnweb.freebsd.org/base/?view=revision&amp;revision=r364182'>was taught</a>
+where to find base .lua modules in order to support <code>require</code> of .lua modules
+to be provided by the base system. flua also <a href='https://svnweb.freebsd.org/base/?view=revision&amp;revision=r364222'>gained support</a>
+for <code>require</code> of binary modules.
+</p>
+<p>A review for <a href='https://reviews.freebsd.org/D26080'>libjail bindings</a> has also
+been submitted, pending review. libjail is an essential component if one wants
+to be able to write jail management utilities in flua.
+</p>
+<p>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):
+</p>
+<ul>
+<li><p>libcrypt
+</p></li>
+<li><p>libexpat
+</p></li>
+<li><p>libnv
+</p></li>
+<li><p>libxo
+</p>
+</li></ul>
+There is also a small list of scripts that would do well with a port to flua:
+
+<ul>
+<li><p>certctl(8)
+</p></li></ul>
+</body></project>
+<project cat='proj'>
+<title>NFS over TLS implementation</title>
+
+<contact>
+<person>
+<name>Rick Macklem</name>
+<email>rmacklem@freebsd.org</email>
+</person>
+</contact>
+
+<body><p>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.
+</p>
+<p>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.
+</p>
+<p>The coding for this project has now been completed.
+All required changes to the NFS and kernel RPC code have
+been committed to -CURRENT.
+The daemons are now believed to be complete, but will
+remain in base/projects/nfs-over-tls until -CURRENT
+has an OpenSSL library with the kernel TLS support
+incorporated in it.
+If this does not happen for FreeBSD-13, hopefully the
+patched OpenSSL and the daemons can become ports.
+</p>
+<p>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.
+</p>
+<p>While setting up system(s) for testing is still a little awkward,
+<a href='https://people.freebsd.org/~rmacklem/nfs-over-tls-setup.txt'>the documentation is now available for those who want to help with testing</a>.
+</p>
+<p>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.
+</p>
+<p>Third party testing would be appreciated.
+</p>
+</body></project>
+<project cat='proj'>
+<title>syzkaller on FreeBSD</title>
+
+<contact>
+<person>
+<name>Mark Johnston</name>
+<email>markj@FreeBSD.org</email>
+</person>
+</contact>
+
+<body><p>See the syzkaller entry in the 2019q1 quarterly report for an
+introduction to syzkaller.
+</p>
+<p>syzkaller, especially the public syzbot instance, continues to find bugs
+in the FreeBSD kernel. A number of these bugs have been fixed in
+subsystems such as the VFS name cache, the TCP and SCTP stacks, pf(4),
+the unix domain socket implementation, and the Linuxulator.
+</p>
+<p>The FreeBSD Foundation sponsored some work to enable cross-OS fuzzing.
+This makes it possible to fuzz the Linuxulator using syzkaller's Linux
+target. This effort quickly found several bugs; once the support is
+committed upstream we will hopefully be able to leverage syzbot to gain
+continuous testing of the Linux system call interface in addition to the
+native and 32-bit compatibility interfaces.
+</p>
+<p>Some work was also done to enable running syzkaller in a FreeBSD jail,
+with the eventual aim of making it easy to distribute binary images
+containing everything required to immediately start running syzkaller on
+a new host. Currently a number of setup steps are required, making
+deployment somewhat painful.
+</p>
+<p>Sponsor: The FreeBSD Foundation
+</p></body></project>
+<project cat='kern'>
+<title>DRM Drivers Update</title>
+
+<links>
+<url href='https://github.com/freebsd/drm-kmod/'>drm-kmod</url>
+</links>
+
+<contact>
+<person>
+<name>Emmanuel Vadot</name>
+<email>manu@FreeBSD.Org</email>
+</person>
+</contact>
+
+<body><p>The drm drivers for FreeBSD 13-CURRENT have been updated to match Linux 5.4.62
+Then graphics/drm-current-kmod have been updated to follow this LTS release of Linux.
+</p>
+<p>For now graphics/drm-devel-kmod is also tracking this release but will be updated
+to a later revision of Linux drm drivers in the near future.
+</p>
+<p>A lot of linuxkpi code was removed from the ports or replaced with a BSD
+licenced implementation.
+</p>
+<p>Sponsor: The FreeBSD Foundation
+</p></body></project>
+<project cat='kern'>
+<title>DTS Update</title>
+
+<contact>
+<person>
+<name>Emmanuel Vadot</name>
+<email>manu@FreeBSD.org</email>
+</person>
+</contact>
+
+<body><p>DTS files (Device Tree Sources) were updated to be on par with Linux 5.8 for
+HEAD and 5.6 for the 12-STABLE branch.
+</p></body></project>
+<project cat='kern'>
+<title>DesignWare Ethernet adapter driver improvements</title>
+
+<links>
+<url href='https://github.com/gonzoua/freebsd/tree/rk_eth'>WIP branch</url>
+</links>
+
+<contact>
+<person>
+<name>Oleksandr Tymoshenko</name>
+<email>gonzo@FreeBSD.org</email>
+</person>
+</contact>
+
+<body><p>DesignWare Ethernet adapter IP is used in Rockchip and Allwinner SoCs.
+The driver was updated with following fixes:
+</p>
+<ul>
+<li><p>Initialize clocks instead of relying on u-boot to do the right thing.
+</p></li>
+<li><p>Sense media type and adjust controller configuration accordingly.
+</p></li>
+<li><p>Add support for RMII PHY mode.
+</p>
+</li></ul>
+Yet uncommitted changes include performance optimisation by adding
+<p>support for multi-segment mbuf transmission. The next step is to
+try to get more performance boost by using interrupt coalescence.
+</p></body></project>
+<project cat='kern'>
+<title>Google Summer of Code’20 Project - eBPF XDP Hooks</title>
+
+<links>
+<url href='https://github.com/Ankurk99/freebsd/tree/ebpf-import'>Github diff link</url>
+<url href='https://wiki.freebsd.org/SummerOfCode2020Projects/eBPFXDPHooksl'>Project wiki</url>
+</links>
+
+<contact>
+<person>
+<name>Ankur Kothiwal</name>
+<email>ankur@freebsd.org</email>
+</person>
+</contact>
+
+<body><p>The eBPF eXpress Data Path (XDP) allows eBPF programs to be run to filter
+received packets as early as possible, avoiding unnecessary processing
+overhead before the filter is run. The goal of this project is to extend an
+existing FreeBSD network driver (a virtual NIC like a VirtIO if_vtnet) to
+be able to call into an eBPF program when processing a newly received
+packet. In short, with XDP the driver must PASS (accept and process normally), DROP,
+TX or REDIRECT the packet as specified by the program. eBPF helper
+functions and maps for aiding in packet filtering will also be
+implemented.
+</p>
+<p>Implemented:
+</p><ul>
+<li><p>Register a eBPF probe when an interface is registered with pfil.
+</p></li>
+<li><p>Activating eBPF probe.
+</p></li>
+<li><p>Create hooks and link them to the pfil head when the eBPF XDP probe is
+ activated and successfully list the XDP probes.
+</p></li>
+<li><p>Create a xdp_rx function which will pass the received packets to the
+ eBPF program where the packets can be further processed. This function will
+ return XDP actions: DROP and PASS.
+</p></li>
+<li><p>Register the xdp hook and link it to the pfil head.
+</p></li>
+<li><p>Write an eBPF program to process (currently drop and pass) ICMP traffic -
+ This is to test that the hook is working properly.
+</p></li>
+<li><p>Write a loader function to load the ICMP filter program to the kernel.
+</p>
+</li></ul>
+Future Work:
+<ul>
+<li><p>Currently we can only attach the XDP hook to PASS and DROP the packets -
+ The work on detaching the hook is left.
+</p></li>
+<li><p>The XDP action to “TX” and “REDIRECT” the packets.
+</p>
+</li></ul>
+Final Deliverables:
+<ul>
+<li><p>Implemented XDP hook to pass and drop packets.
+</p></li>
+<li><p>Created a loader program to attach the eBPF program to the kernel.
+</p></li>
+<li><p>A test program to DROP ICMP filter.
+</p>
+</li></ul>
+This code was done under the Google Summer of Code 2020 under the guidance
+<p>of Ryan Stone (rstone@). The eBPF implementation for FreeBSD
+is still a work in progress and FreeBSD doesn’t support eBPF yet. The
+basic implementation for eBPF was a <a href='https://wiki.freebsd.org/SummerOfCode2018Projects/eBPF'>GSoC’18 project</a>,
+and is still under development. This project is based on that implementation so the XDP
+implementation for FreeBSD can only be merged into the FreeBSD source code
+once it supports eBPF.
+</p>
+<p>Currently this code is a work in progress and is merged to Ryan Stone’s
+<a href='https://github.com/rysto32/freebsd/tree/ebpf-import'>branch with support for the eBPF implementation</a>.
+</p>
+<p>Sponsor: Google Summer of Code
+</p></body></project>
+<project cat='kern'>
+<title>ENA FreeBSD Driver Update</title>
+
+<links>
+<url href='https://github.com/amzn/amzn-drivers/blob/master/kernel/fbsd/ena/README'>ENA README</url>
+</links>
+
+<contact>
+<person>
+<name>Michal Krawczyk</name>
+<email>mk@semihalf.com</email>
+</person>
+<person>
+<name>Artur Rojek</name>
+<email>ar@semihalf.com</email>
+</person>
+<person>
+<name>Marcin Wojtas</name>
+<email>mw@semihalf.com</email>
+</person>
+</contact>
+
+<body><p>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.
+</p>
+<p>Completed since the last update:
+</p><ul>
+<li><p>Fix ENA compilation in case it is integrated into the kernel binary.
+</p></li>
+<li><p>MFC of the ENA v2.2.0 driver to the FreeBSD 12.2.
+</p>
+</li></ul>
+Work in progress:
+<ul>
+<li><p>Add feature that allows reading extra ENI (Elastic Network Interface)
+ metrics about exceeding BW/pps limits.
+</p></li>
+<li><p>Introduce full kernel RSS API support.
+</p></li>
+<li><p>Allow reconfiguration of the RSS indirection table and hash key.
+</p></li>
+<li><p>Evaluation and prototyping of the driver port to the iflib framework.
+</p>
+</li></ul>
+Sponsor: Amazon.com Inc
+</body></project>
+<project cat='kern'>
+<title>IPSec Extended Sequence Number (ESN) support</title>
+
+<contact>
+<person>
+<name>Grzegorz Jaszczyk</name>
+<email>jaz@semihalf.com</email>
+</person>
+<person>
+<name>Patryk Duda</name>
+<email>pdk@semihalf.com</email>
+</person>
+<person>
+<name>Marcin Wojtas</name>
+<email>mw@semihalf.com</email>
+</person>
+</contact>
+
+<body><p>Extended Sequence Number (ESN) is IPSec extension defined in <a href='https://tools.ietf.org/html/rfc4303#section-2.2.1'>RFC4303 Section 2.2.1</a>.
+It makes possible to implement high-speed IPSec implementations where standard, 32-bit sequence number is not sufficient.
+A key feature of the ESN is that only low order 32 bits of sequence number are transmitted over the wire.
+High-order 32 bits are maintained by sender and receiver. Additionally high-order bits are included in the computation of Integrity Check Value (ICV) field.
+</p>
+<p>Extended Sequence Number support contains following:
+</p>
+<ul>
+<li><p>Modification of existing anti-replay algorithm to fulfil ESN requirements.
+</p></li>
+<li><p>Trigger soft lifetime expiration at 80% of UINT32_MAX when ESN is disabled.
+</p></li>
+<li><p>Implement support for including ESN into ICV in cryptosoft engine in both
+ encrypt and authenticate mode (eg. AES-CBC and SHA256 HMAC) and combined
+ mode (eg. AES-GCM).
+</p></li>
+<li><p>Implement support for including ESN into ICV in AES-NI engine in both
+ encrypt and authenticate mode and combined mode.
+</p>
+</li></ul>
+Completed since the last update:
+
+<ul>
+<li><p>Adjust implementation of crypto part to the reworked Open Crypto Framework.
+</p></li>
+<li><p>Move the core ESN implementation from the crypto drivers to netipsec layer.
+</p></li>
+<li><p>Make use of the newly introduced crp_aad mechanism for combined modes.
+</p></li>
+<li><p>Introduce minor fixes and improvements.
+</p>
+</li></ul>
+TODO:
+
+<ul>
+<li><p>Complete review process in Phabricator and merge patches in the tree.
+</p>
+</li></ul>
+Sponsor: Stormshield
+
+</body></project>
+<project cat='kern'>
+<title>NXP ARM64 SoC support</title>
+
+<contact>
+<person>
+<name>Marcin Wojtas</name>
+<email>mw@semihalf.com</email>
+</person>
+<person>
+<name>Artur Rojek</name>
+<email>ar@semihalf.com</email>
+</person>
+<person>
+<name>Dawid Gorecki</name>
+<email>dgr@semihalf.com</email>
+</person>
+</contact>
+
+<body><p>The Semihalf team initiated working on FreeBSD support for the
+<a href='https://www.nxp.com/products/processors-and-microcontrollers/arm-based-processors-and-mcus/qoriq-layerscape-arm-processors/qoriq-layerscape-1046a-and-1026a-multicore-communications-processors:LS1046A'>NXP LS1046A SoC</a>
+</p>
+<p>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.
+</p>
+<p>Completed since the last update:
+</p><ul>
+<li><p>Upstreaming of the QorIQ SDHCI driver (r365054).
+</p>
+</li></ul>
+With above the current Semihalf upstreaming activity is complete.
+
+<p>The major out-of-tree supported components:
+</p><ul>
+<li><p>DPAA network controller support.
+</p></li>
+<li><p>QSPI controller support.
+</p>
+</li></ul>
+They work on 11.2-RELEASE, but still require significant
+<p>effort to adopt to FreeBSD-CURRENT.
+</p>
+<p>Sponsor: Alstom Group
+</p></body></project>
+<project cat='kern'>
+<title>Addition of PowerPC64LE Architecture</title>
+
+<links>
+<url href='https://lists.freebsd.org/pipermail/freebsd-ppc/2020-August/012043.html'>Early notes</url>
+<url href='https://lists.freebsd.org/pipermail/freebsd-ppc/2020-September/012098.html'>Announcement</url>
+</links>
+
+<contact>
+<person>
+<name>Brandon Bergren</name>
+<email>bdragon@freebsd.org</email>
+</person>
+</contact>
+
+<body><p>As of r366063, experimental support for little-endian PowerPC64 (PowerPC64LE)
+is available in -CURRENT for POWER8 and POWER9 machines.
+</p>
+<p>In 2010, when FreeBSD was ported to PowerPC64, the average
+user would have been using a G5 PowerMac, a purely big-endian
+machine.
+</p>
+<p>While, at the time, a 32-bit PowerPC machine could run in little-endian,
+as well as POWER6 and POWER7, in practice, the complexities involved
+in managing it at the kernel level and lack of firmware support made it
+infeasible to support.
+</p>
+<p>When IBM designed POWER8, one main focus was to improve little-endian support,
+and bring it up to parity with big-endian.
+</p>
+<p>This improved support makes it practical to support a little-endian operating
+environment on what is traditionally a primarily big-endian platform.
+</p>
+<p>In 2020, with POWER9 being affordable for many users thanks to the Raptor
+Blackbird, semi-easy access to surplus POWER8 hardware, IBM having
+a major future focus on POWER little-endian, and the decay of big-endian
+support in modern video cards and graphical environments, there is demand for
+a little-endian version of FreeBSD on POWER.
+</p>
+<p>With FreeBSD/PowerPC64's transition in 2019 to the ELFv2 ABI as part of the
+2019q4 PowerPC on Clang effort, the last major barrier to a little-endian
+port was eliminated.
+</p>
+<p>Since nobody else was working on it, and I had the skillset required to do
+the port, I decided to experiment one weekend with a little-endian kernel
+to see how difficult it would be to port.
+</p>
+<p>It turned out to be a lot more trivial than I was expecting. Three days later
+I had console support in qemu, and after another week of debugging, I had it
+fully up and running on hardware.
+</p>
+<p>FreeBSD PowerPC64LE is now an experimental MACHINE_ARCH in base, and is
+continuing to evolve at a rapid pace.
+</p>
+<p>Big-endian PowerPC64 is still the preferred platform for the foreseeable
+future, and will not be deprecated.
+</p>
+<p>Sponsor: Tag1 Consulting, Inc.
+</p></body></project>
+<project cat='kern'>
+<title>ure - USB 3.0 Gigabit Ethernet Driver update</title>
+
+<links>
+<url href='https://svnweb.freebsd.org/changeset/base/365648'>svn commit: r365648</url>
+<url href='https://www.freebsd.org/security/advisories/FreeBSD-SA-20:27.ure.asc'>FreeBSD-SA-20:27.ure</url>
+<url href='https://reviews.freebsd.org/D25809'>D25809 major update to if_ure</url>
+</links>
+
+<contact>
+<person>
+<name>John-Mark Gurney</name>
+<email>jmg@FreeBSD.org</email>
+</person>
+</contact>
+
+<body><p>The ure is a driver for handling the RealTek ethernet adapters,
+including the RTL8153 USB 3.0 Gigabit ethernet adapters. It is used
+in many ethernet dongles and docking stations.
+</p>
+<p>Previous to this update, the driver was limited in speed. In my
+testing, I was only able to get ~91Mbps. This limit was due to one
+packet per USB transfer. USB has a limit of 8000 transfers per
+second (1500 bytes/pkt * 8000 pkts/sec * 8bits/byte == 96 Mbps).
+This was acceptable for fast ethernet (RTL8152, 100Mbps), but with
+the additional support for Gigabit ethernet, it became a bottleneck.
+</p>
+<p>The updates add sending and receiving multiple packets in a single
+USB transfer, VLAN hardware tagging, and enable TCP and UDP
+checksum offloading. This increased the speed on gigabit ethernet
+to ~940 Mbps.
+</p>
+<p>In doing this work, a security vulnerability was discovered in the
+driver. Due to improper setting of a device register, on some
+devices, it caused packets to be fragmented when they shouldn't be
+and the driver was unable to handle them correctly. This allowed an
+attacker, who could generate large frames (say, ping packets, or
+large TCP transfers), to inject arbitrary packets into the network
+stack. This could allow the attacker to spoof traffic from other
+machines, and bypass VLAN protections. See the SA for more
+information.
+</p>
+<p>As part of this work, a script was created to run tests to
+validate that basic functionality of the driver (w/o options) work
+properly, and then iterate over each option to make sure that they
+function properly. This will be released at some point in the
+future.
+</p>
+<p>If you're interested in helping out, or testing it, let me know.
+</p></body></project>
+<project cat='kern'>
+<title>Stateless hardware offloads for VXLANs</title>
+
+<links>
+<url href='https://svnweb.freebsd.org/base?view=revision&amp;revision=r365867'>r365867</url>
+<url href='https://svnweb.freebsd.org/base?view=revision&amp;revision=r365868'>r365868</url>
+<url href='https://svnweb.freebsd.org/base?view=revision&amp;revision=r365869'>r365869</url>
+<url href='https://svnweb.freebsd.org/base?view=revision&amp;revision=r365870'>r365870</url>
+<url href='https://svnweb.freebsd.org/base?view=revision&amp;revision=r365871'>r365871</url>
+<url href='https://tools.ietf.org/html/rfc6935'>RFC6935</url>
+</links>
+
+<contact>
+<person>
+<name>Navdeep Parhar</name>
+<email>np@FreeBSD.org</email>
+</person>
+</contact>
+
+<body><p>VXLAN (Virtual eXtensible LAN) is a tunneling protocol in which Layer 2
+traffic for a virtual LAN is encapsulated in UDP and transferred over
+Layer 3 networks between VTEPs (VXLAN Tunnel End Points). Traffic on
+the wire has two sets of networking headers: the headers for the
+encapsulation and the headers of the traffic being encapsulated. VXLANs
+are supported by if_vxlan(4) on FreeBSD.
+</p>
+<p>Modern NICs commonly support header checksum insertion and verification,
+TSO (TCP Segmentation Offload) on transmit, and RSS for load
+distribution on receive. But the default is to operate on the outermost
+headers. Some NICs can operate on the inner encapsulated frames as
+well. The commits listed above allow if_vxlan(4) to take advantage of
+such NICs.
+</p>
+<p>r365867 and r365868 add new mbuf checksum flags and ifnet capabilities.
+r365870 implements the kernel parts of the new capabilities and updates
+if_vxlan(4) to make use of them. r365871 implements driver support for
+the new capabilities in cxgbe(4).
+</p>
+<p>VXLAN and other tunneling protocols that use UDP explicitly allow zero
+checksum in the outer UDP header, even with IPv6. r365869 adds support
+for configuring one UDP/IPv6 port where zero checksums are allowed.
+</p>
+<p>This work was sponsored by Chelsio Communications and was implemented
+and tested using T6 (Terminator 6) NICs supported by cxgbe(4). It is
+available in 13.0-CURRENT (head) right now and will be available in
+12-STABLE in the future.
+</p>
+<p>VXLANs can be created as usual and will automatically have checksum and
+TSO capabilities if the underlying physical interface supports VXLAN
+stateless offloads. Use ifconfig to list, disable, and enable checksum
+capabilities on the VXLAN interface. Use https://bugs.freebsd.org/bugzilla/
+to report bugs.
+</p>
+<p>Future work:
+</p><ul>
+<li><p>Direct call into a vxlan input routine from the driver's receive routine.
+</p></li>
+<li><p>LRO support in if_vxlan(4).
+</p></li>
+<li><p>GENEVE support.
+</p>
+</li></ul>
+Sponsor: Chelsio Communications
+</body></project>
+<project cat='kern'>
+<title>Wireless updates</title>
+
+<links>
+<url href='https://lists.freebsd.org/mailman/listinfo/freebsd-wireless'>The freebsd-wireless mailing list</url>
+<url href='https://github.com/erikarn/athp'>athp github repository</url>
+</links>
+
+<contact>
+<person>
+<name>Adrian Chadd</name>
+<email>adrian@FreeBSD.org</email>
+</person>
+<person>
+<name>Bjoern A. Zeeb</name>
+<email>bz@FreeBSD.org</email>
+</person>
+</contact>
+
+<h3>net80211 and infrastructure, driver updates, and upcoming 12.2 Release</h3>
+
+<body><p>The following works happened in FreeBSD HEAD (some already in Q2) and were
+merged for 12.2-BETA2 and include net80211 and driver updates for better 11n
+and upcoming 11ac support.
+</p>
+<p>In more detail, this includes an ath(4) update, some run(4) 11n support, 11n for otus(4),
+A-MPDU, A-MSDU, A-MPDU+A-MSDU and Fast frames options, scanning fixes,
+enhanced PRIV checks for jails, restored parent device name printing,
+improvements for upcoming VHT support, lots of under-the-hood infrastructure
+improvements, new device IDs, and debug tools updates.
+</p>
+<p>If you have a chance please test before the release.
+</p>
+<h3>Atheros 11ac driver athp</h3>
+
+<p>In the last three months the athp(4) port of the ath10k driver has progressed
+well. Adrian reports the following important changes:
+</p><ul>
+<li><p>Per-node transmit buffering was implemented, required for correct hostap
+ and QCA6174 behaviour.
+</p></li>
+<li><p>Issues with ignoring sending some management frames got fixed; null-data
+ frames were being filtered out and this caused undesirable hostap behaviour.
+</p></li>
+<li><p>Transmit path refactoring reduced code duplication.
+</p></li>
+<li><p>A fix on firmware start / VAP running tracking no longer stops
+ the first VAP from coming active after VAP creation / ifconfig up.
+</p></li>
+<li><p>Correcting hostap mode PHY configuration now allows non-VHT stations to
+ associate and correctly exchange data with a VHT AP.
+</p></li>
+<li><p>Addition of a crypto key configuration cache in the driver ensures the
+ ieee80211_key details are available after the key is deleted; net80211
+ would reuse or free the state before the driver task would finish the
+ firmware command.
+</p>
+</li></ul>
+<h3>Newer Intel Wireless device support</h3>
+
+<p>Initial work was done to integrate net80211 support in the LinuxKPI compat
+layer to get the wireless parts going.
+In addition, upstreaming code changes and working through problems and review
+started on two sides. One was trying to get mostly compile time changes
+upstreamed to the iwlwifi driver. The other is sorting out conflicting
+LinuxKPI changes to not break the DRM graphics drivers.
+Bjoern hopes that with some of that sorted out, he can soon go back to focus
+on the wireless parts and produce a new snapshot.
+</p>
+<h3>rtw88 and brcmfmac</h3>
+
+<p>As the Intel driver port and LinuxKPI advance, both the rtw88, and to a lower
+degree the brcmfmac, ports benefit from that.
+Bjoern lately also got a brcmfmac PCIe card and started to port support for
+that.
+This for the moment remains a free-time project.
+</p>
+<p>Work by Bjoern was sponsored by: Rubicon Communications, LLC (d/b/a "Netgate") and The FreeBSD Foundation
+</p></body></project>
+<project cat='kern'>
+<title>ZSTD Compression in ZFS</title>
+
+<contact>
+<person>
+<name>Allan Jude</name>
+<email>allanjude@freebsd.org</email>
+</person>
+</contact>
+
+<body><p>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).
+</p>
+<p>This effort to complete the integration of ZSTD into ZFS is
+funded by the FreeBSD Foundation.
+</p>
+<p>During the third quarter the integrating of ZSTD into OpenZFS
+was completed in the upstream OpenZFS repository, and the new
+OpenZFS 2.0 codebase was imported into 13-CURRENT.
+Completed milestones in this project:
+</p>
+<ul>
+<li><p>Importing ZSTD 1.4.5 into OpenZFS, using the recent upstream zstd features that make it easier to embed zstd in other projects.
+</p></li>
+<li><p>Changing the way compression levels are tracked and inherited.
+</p></li>
+<li><p>Save and restore the compression level via an embedded block header.
+</p></li>
+<li><p>Also store the version of zstd used in the embedded block header, for future-proofing. The checksum of a block may not match if zstd is upgraded, since it may compress the block more.
+</p></li>
+<li><p>Add tests to ensure zstd compression and metadata survive ZFS replication.
+</p></li>
+<li><p>Resolve possible negative interactions with L2ARC and ZFS Native Encryption.
+</p></li>
+<li><p>Fix bug with L2ARC if the Compressed ARC feature is disabled.
+</p></li>
+<li><p>Improve the ZFS feature activation code, so that zstd cannot create pools that will panic older versions of ZFS.
+</p>
+</li></ul>
+With these changes, upgraded pools can compress data with zstd
+<p>or zstd-fast, across a wide range of different compression levels.
+This will allow the storage administrator to select the
+performance-vs-compression tradeoff that best suits their needs.
+</p>
+<p>Tasks remaining to be completed:
+</p>
+<ul>
+<li><p>Add a section to the FreeBSD Handbook ZFS chapter about zstd
+</p></li>
+<li><p>Create more documentation around selecting a suitable compression level
+</p></li>
+<li><p>Finish support for ZSTD in the FreeBSD boot loader (Warner Losh <a href='mailto:imp@freebsd.org'>imp@freebsd.org</a>)
+</p>
+</li></ul>
+Sponsor: The FreeBSD Foundation
+</body></project>
+<project cat='arch'>
+<title>CheriBSD 2020 Q3</title>
+
+<links>
+http://www.cheri-cpu.org
+https://github.com/CTSRD-CHERI/cheribsd
+https://fett.darpa.mil
+https://www.morello-project.org
+https://developer.arm.com/architectures/cpu-architecture/a-profile/morello
+</links>
+
+<contact>
+<person>
+<name>Alex Richardson</name>
+<email>arichardson@FreeBSD.org</email>
+</person>
+<person>
+<name>Andrew Turner</name>
+<email>andrew@FreeBSD.org</email>
+</person>
+<person>
+<name>Brooks Davis</name>
+<email>brooks@FreeBSD.org</email>
+</person>
+<person>
+<name>Edward Tomasz Napierala</name>
+<email>trasz@FreeBSD.org</email>
+</person>
+<person>
+<name>George Neville-Neil</name>
+<email>gnn@FreeBSD.org</email>
+</person>
+<person>
+<name>Jessica Clarke</name>
+<email>jrtc27@FreeBSD.org</email>
+</person>
+<person>
+<name>John Baldwin</name>
+<email>jhb@FreeBSD.org</email>
+</person>
+<person>
+<name>Robert Watson</name>
+<email>rwatson@FreeBSD.org</email>
+</person>
+<person>
+<name>Ruslan Bukin</name>
+<email>br@FreeBSD.org</email>
+</person>
+</contact>
+
+<h3>CheriBSD Status</h3>
+
+<body><p>CheriBSD extends FreeBSD to implement memory protection and software
+compartmentalization features supported by the CHERI instruction-set
+extensions. There are three architectural implementations of the
+CHERI protection model: CHERI-MIPS, CHERI-RISC-V, and Arm's forthcoming
+experimental Morello processor (due late 2021). CheriBSD is a research
+operating system with a stable baseline implementation into which
+various new research features have been, or are currently being, merged:
+</p>
+<ul>
+<li><p>Arm Morello - We are preparing to open source our adaptation of
+ CheriBSD to Arm's Morello architecture. The Morello branch is being
+ updated to the most recent CheriBSD baseline, and patches are in review
+ for upstreaming to our open-source repository. CheriBSD currently boots
+ and runs statically linked CheriABI binaries on the Morello simulator,
+ and dynamic linking support is in progress, with OS and toolchain bugs
+ being worked on. We aim to make a first CheriBSD/Morello snapshot
+ available alongside other open-source Morello software in mid-October
+ 2020, however, our target for a more mature and usable implementation is
+ December 2020.
+</p>
+</li>
+<li><p>Kernel spatial memory safety (pure-capability kernel) - The current
+ CheriBSD kernel is a hybrid C program where only pointers to userspace
+ are CHERI capabilities. This ensures that the kernel follows the
+ intent of the application runtime and cannot be used to defeat
+ bounds on application pointers. We have developed and will soon
+ merge a pure-capability kernel where all pointers in the kernel are
+ appropriately bounded capabilities. This vastly reduces the opportunity
+ for buffer overflows. This spatial memory safety lays the
+ groundwork for future work such as device driver compartmentalization
+ and kernel temporal safety.
+</p>
+</li>
+<li><p>Userspace heap temporal memory safety (Cornucopia) - CHERI
+ capabilities provide the necessary features to enable
+ robust and efficient revocation of freed pointers. With <a href='https://www.cl.cam.ac.uk/research/security/ctsrd/pdfs/2020oakland-cornucopia.pdf'>Cornucopia</a>
+ we have implemented a light-weight revocation framework providing
+ protection from use-after-reallocation bugs with an average cost below
+ 2%. We aim to bring these overheads down further over the next year and
+ merge this functionality into the mainline CheriBSD.
+</p>
+</li>
+<li><p>We have been working on updating the arm64 bhyve from Politehnica
+ University of Bucharest to have it committed to FreeBSD. We have been
+ upstreaming initial changes to help support this.
+</p>
+</li>
+<li><p>Baseline FreeBSD improvements - We are upstreaming (to FreeBSD) various
+ bug fixes and tweaks for PCIe support, and support for the System MMU (SMMU)
+ that will be present on the N1SDP and Morello SoCs. We have upstreamed
+ support for cross-building FreeBSD from macOS and Linux (with some
+ limitations; see separate entry on crossbuilding). We have also fixed
+ implementation bugs in the RISC-V ABI.
+</p>
+</li></ul>
+<h3>CHERI Documentation and Exercises</h3>
+
+<ul>
+<li><p>We have released [Capability Hardware Enhanced RISC Instructions: CHERI
+ Instruction-Set Architecture (Version 8)](https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-951.pdf).
+ Notable changes include promotion of CHERI-RISC-V to non-experimental
+ and discussion of Arm's Morello prototype.
+</p>
+</li>
+<li><p>We have developed a set of [Adversarial CHERI Exercises and
+ Missions](https://ctsrd-cheri.github.io/cheri-exercises) to introduce security
+ researchers to CHERI protections.
+</p></li></ul>
+</body></project>
+<project cat='arch'>
+<title>FreeBSD/RISC-V Project</title>
+
+<links>
+<url href='https://wiki.freebsd.org/riscv'>Wiki</url>
+</links>
+
+<contact>
+<person>
+<name>Mitchell Horne</name>
+<email>mhorne@FreeBSD.org</email>
+</person>
+</contact>
+<body><p>Contact: <a href='https://lists.FreeBSD.org/mailman/listinfo/freebsd-riscv'>freebsd-riscv Mailing List</a><br />
+Contact: IRC #freebsd-riscv on freenode<br />
+</p>
+<p>The FreeBSD/RISC-V project is providing support for running FreeBSD on the
+<a href='https://riscv.org/'>RISC-V Instruction Set Architecture</a>.
+</p>
+<p>This quarter saw several important bug fixes. A number of hangs in the system
+were identified and addressed, and a bug in QEMU's implementation of the
+Platform Level Interrupt Controller was fixed. This fix is included in the new
+<code>devel/qemu50</code> and <code>devel/qemu-devel</code> ports.
+</p>
+<p>The end result of these fixes is that the test suite can now be reliably run to
+completion in QEMU. The entire run takes several hours, so CI has been
+configured to run the job once a day. There is active effort into reducing the
+time it takes to run the entire test suite.
+</p>
+<p>A new u-boot port was created: <code>sysutils/u-boot-qemu-riscv64</code>. This variant can
+be used as a secondary bootloader alongside OpenSBI to load and launch FreeBSD's
+<code>loader(8)</code> from an EFI System Partition.
+</p>
+<p>Next quarter will likely bring further fixes to address some of the failing test
+cases.
+</p></body></project>
+<project cat='doc'>
+<title>DOCNG on FreeBSD</title>
+
+<links>
+<url href='https://gitlab.com/carlavilla/freebsd-hugo-website'>DOCNG Website Repo</url>
+<url href='https://gitlab.com/carlavilla/freebsd-hugo-documentation'>DOCNG Documentation Repo</url>
+<url href='https://gitlab.com/carlavilla/freebsd-hugo-data'>DOCNG Share Repo</url>
+</links>
+
+<contact>
+<person>
+<name>Sergio Carlavilla</name>
+<email>carlavilla@FreeBSD.org</email>
+</person>
+</contact>
+
+<body><p>The Doc New Generation project aims to convert the website and all
+existing documentation to Hugo/AsciiDoctor. Right now almost
+everything is converted as you can see in the repositories.
+</p>
+<p>The objective of using Hugo and AsciiDoctor is to reduce the
+learning curve and let people to start quickly with our documentation
+system. Other benefits of using Hugo is that we can use other
+technologies aside from AsciiDoctor, like MarkDown, RST, Pandoc, etc.
+</p>
+<p>The remaining tasks include:
+</p><ul>
+<li><p>Finish the conversion of some books to AsciiDoctor.
+</p></li>
+<li><p>Get some tweaks in the CSS to be responsive.
+</p></li>
+<li><p>Add AsciiDoctor extensions to create an index of tables and figures.
+</p></li>
+<li><p>Make a general review.
+</p>
+</li></ul>
+The dates for making the migration have yet to be discussed.
+
+<p>Patches, comments and objections are always welcome.
+</p></body></project>
+<project cat='ports'>
+<title>Update to grub-bhyve</title>
+
+<links>
+<url href='https://gitlab.com/ctuffli/grub'>grub-bhyve Git Repository</url>
+</links>
+
+<contact>
+<person>
+<name>Chuck Tuffli</name>
+<email>chuck@freebsd.org</email>
+</person>
+</contact>
+
+<body><p>bhyve is the hypervisor included in FreeBSD and other operating systems
+used to run virtual machines. When not using a boot ROM (i.e. UEFI), the
+user must load the guest operating system for bhyve. For non-FreeBSD
+guests, the loader is a version of GNU GRUB (a.k.a the GNU GRand Unified
+Bootloader) modified to interface with bhyve. This work is an effort to
+both update the base GRUB code to the latest version as well as improve
+the usability on FreeBSD.
+</p>
+<p>The current <a href='https://www.freshports.org/sysutils/grub2-bhyve/'>grub-bhyve</a>
+is based on an older version of GRUB (circa 2015) and thus is missing
+more recent additions such as XFS file system and
+<a href='https://www.syslinux.org/'>syslinux</a> support. With the update,
+installing CentOS, for example, now does not require the extra step of
+changing the default file system to something other than XFS.
+</p>
+<p>Internally, the code has been restructured to be its own "platform"
+which should make it easier to keep in sync with upstream development.
+The major improvement is the ability to automatically find and load the
+GRUB configuration file from the guest disk image. With this change, it
+is not necessary to create a device map file or specify which Linux
+kernel or initrd image to use. More importantly, if the guest image
+updates its GRUB configuration, for example after updating the kernel,
+no changes are needed when invoking grub-bhyve. Note, this feature
+requires a new "disk" option:
+</p>
+<p> # grub-bhyve --disk=/zroot/vms/u18-mini/disk0.img --vm=u18-mini
+</p>
+<p>The automatic configuration file detection works with both GRUB
+configuration files (e.g. CentOS, Ubuntu) as well as syslinux
+configuration (e.g. Alpine). For the adventurous, there is experimental
+support for Fedora's BootLoaderSpec (a.k.a. <code>blscfg</code>) on the blscfg
+branch of the grub-bhyve Git repository.
+</p>
+<p>The code has been tested on a few Linux variants, but it would benefit
+from wider testing (and bug reports!). The new version does not have a
+Port but is easily built on FreeBSD. After cloning / downloading the
+source, run:
+</p>
+<p> $ PYTHON=python3.7 ./bootstrap
+ $ MAKE=gmake ./configure --with-platform=bhyve
+ $ gmake
+</p>
+<p>The resulting binary, <code>grub-bhyve</code>, will be in the <code>grub-core/</code>
+directory. If you have success or troubles with it, please let me know.
+</p></body></project>
+<project cat='ports'>
+<title>KDE on FreeBSD</title>
+
+<links>
+<url href='https://freebsd.kde.org/'>KDE FreeBSD</url>
+<url href='https://community.kde.org/FreeBSD'>KDE Community FreeBSD</url>
+</links>
+
+<contact>
+<person>
+<name>Adriaan de Groot</name>
+<email>kde@FreeBSD.org</email>
+</person>
+</contact>
+
+<body><p>The KDE on FreeBSD project aims to package all of the software
+produced by the KDE Community for the FreeBSD ports tree.
+The software includes a full desktop environment called KDE Plasma,
+an IDE with the name <a href='https://www.kdevelop.org/'>KDevelop</a>,
+a PIM suite known as <a href='https://kontact.kde.org/'>Kontact</a>
+and hundreds of other applications that can be used on
+any FreeBSD machine.
+</p>
+<p>With the continuation of the ever-so-peculiar era of
+almost-only-online, the KDE community has shifted gears
+and also gone for online events. The yearly conference,
+<a href='https://akademy.kde.org/2020/'>Akademy</a>,
+was conducted online over video calls.
+Meanwhile, software continues to be released,
+so this quarter the kde@ team:
+</p>
+<ul>
+<li><p>Put the beta of the next version of KDE Plasma, scheduled for
+ official release in October 2020, into the
+ <a href='https://community.kde.org/FreeBSD/Setup/Area51'>Area51 development</a> tree.
+ Area51 is a fork of the FreeBSD ports tree where new development for
+ KDE ports happens.
+</p></li>
+<li><p>The monthly regular updates to the KDE Plasma desktop landed on-time
+ and safely.
+</p></li>
+<li><p>With three months in a quarter, there were also three releases of
+ KDE Frameworks 5, including a new framework for handling DAV jobs.
+</p></li>
+<li><p>The June applications update and its .1 release landed a bit late,
+ but brings with it the usual raft of updates to KDE applications and libraries,
+</p></li>
+<li><p>A new <a href='https://www.digikam.org/'>Digikam</a> release, which arrived in
+ the ports tree on the day of its release.
+</p></li>
+<li><p>A new <a href='https://www.kdevelop.org/'>KDevelop</a> release arrived a day
+ after its release. This update contains a number of crash fixes
+ for refactoring support.
+</p></li>
+<li><p>Qt was updated to Qt 5.15, the last in the Qt5 series and an LTS
+ version. Bugfix releases are expected, but the next major Qt will
+ be Qt 6.
+</p>
+</li></ul>
+On the infrastructure front, August saw some minor updates to CMake and ninja.
+<p>As usual, kde@ continues to support the work of xorg@ and gnome@ in maintaining
+the Free Desktop stack on FreeBSD, including XOrg, poppler, and xdg-utils.
+A new <code>MAINTAINER</code> group, desktop@, has been created to provide
+shared ownership of that shared stack.
+</p>
+<p>With Python2 deprecation looming, the build system for QtWebEngine --
+itself a fork of Chromium -- is becoming a pressing issue in Q4
+and will no doubt chew up a lot of time in the coming months.
+</p></body></project>
+<project cat='third'>
+<title>Potluck - Flavour &amp; Image Repository for pot</title>
+
+<links>
+<url href='https://potluck.honeyguide.net/'>Potluck Repository &amp; Project</url>
+<url href='https://github.com/hny-gd/potluck'>Potluck on github</url>
+<url href='https://pot.pizzamig.dev'>pot project</url>
+</links>
+
+<contact>
+<person>
+<name></name>
+<email></email>
+</person>
+</contact>
+
+<body><p>pot is a jail management tool that <a href='https://www.freebsd.org/news/status/report-2020-01-2020-03.html#pot-and-the-nomad-pot-driver'>also supports orchestration through nomad</a>.
+</p>
+<p>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.
+</p>
+<p>In the last quarter, an initial set of Nomad, Consul and Traefik images has been created that are sufficient to run a simple virtual datacenter out of the box. <br />
+<a href='https://honeyguide.eu/posts/virtual-dc1/'>A three-part article series explaining how to set this up</a> is also available now.
+</p>
+<p>Furthermore, ready-made images suitable for scheduling via Nomad and Consul in such an environment have been created, e.g. a BackupPC or a Postfix Backup MX service.
+</p>
+<p>Future plans include additional images and exposing more configuration options in the existing images to allow a more flexible usage.
+</p>
+<p>Beside general feedback and tests, additional flavours and patches are very welcome!
+</p>
+<p>Sponsors: Honeyguide GmbH &amp; Honeyguide Group (Pty) Ltd
+## Puppet
+</p>
+<links>
+<url href='https://puppet.com/docs/puppet/latest/puppet_index.html'>Puppet</url>
+<url href='https://puppetcommunity.slack.com/messages/C6CK0UGB1/'>Puppet's FreeBSD slack channel</url>
+<url href='https://puppet.com/docs/bolt/latest/bolt.html'>Bolt</url>
+<url href='https://choria.io/'>Choria</url>
+</links>
+
+<contact>
+<person>
+<name>Puppet Team</name>
+<email>puppet@FreeBSD.org</email>
+</person>
+</contact>
+
+<p>Since out last status report a few years ago, the puppet@ team regularly
+updated the various Puppet ports to follow upstream releases of Puppet
+4, Puppet 5 and Puppet 6. Puppet 4 was removed when it reached EOL.
+</p>
+<p>More recently, an effort was made to enhance Facter 4 so that it can be
+used as a drop-in replacement of Facter 3 on FreeBSD. Facter 4 is a
+Ruby rewrite of Facter 3, the C++ rewrite of Facter 2 which was
+initially in Ruby. As a consequence we have two ports for Facter:
+sysutils/facter is the C++ implementation (Facter 3) and
+sysutils/rubygems-facter is the Ruby implementation (updated from Facter
+2 to Facter 4 a few weeks ago). The Puppet 5 and Puppet 6 ports already
+allow to choose which version of Facter to use. Facter 4 will be the
+default version of Facter with Puppet 7 which is expected to be released
+soon.
+</p>
+<p>We are getting ready to add a port for Puppet 7 as sysutils/puppet7
+when it is available, along with PuppetServer 7 (sysutils/puppetserver7),
+and PuppetDB 7 (databases/puppetdb7).
+</p>
+<p>Regarding orchestration, most Marionette Collective ports have been
+deprecated for a long time, and the last component sysutils/mcollective
+is expected to be deprecated soon: Marionette Collective was not shipped
+anymore with Puppet 6 and Bolt has been made available as a lightweight
+replacement.
+</p>
+<p>Bolt is already available in the ports tree as sysutils/rubygems-bolt),
+but if you are using Marionette Collective, you are invited to look into
+Choria which will reach the ports tree soon as sysutils/choria. Choria
+is a direct evolution of Marionette Collective allowing a smooth
+transition from MCollective. Once Choria is available in the ports
+tree, Marionette Collective will be deprecated.
+</p></body></project>
+ <category>
+ <name>team</name>
+
+ <description>&os; Team Reports</description>
+
+ <p>Entries from the various official and semi-official teams,
+ as found in the <a href="&enbase;/administration.html">Administration
+ Page</a>.</p>
+ </category>
+
+ <category>
+ <name>proj</name>
+
+ <description>Projects</description>
+
+ <p>Projects that span multiple categories, from the kernel and userspace
+ to the Ports Collection or external projects.</p>
+ </category>
+
+ <category>
+ <name>kern</name>
+
+ <description>Kernel</description>
+
+ <p>Updates to kernel subsystems/features, driver support,
+ filesystems, and more.</p>
+ </category>
+
+ <category>
+ <name>arch</name>
+
+ <description>Architectures</description>
+
+ <p>Updating platform-specific features and bringing in support
+ for new hardware platforms.</p>.
+ </category>
+ <category>
+ <name>ports</name>
+
+ <description>Ports</description>
+
+ <p>Changes affecting the Ports Collection, whether sweeping
+ changes that touch most of the tree, or individual ports
+ themselves.</p>
+ </category>
+
+ <category>
+ <name>doc</name>
+
+ <description>Documentation</description>
+
+ <p>Noteworthy changes in the documentation tree, in manpages, or in
+ external books/documents.</p>
+ </category>
+
+ <category>
+ <name>third</name>
+
+ <description>Third-Party Projects</description>
+
+ <p>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.</p>
+ </category>
+
+</report>