Index: head/en_US.ISO8859-1/htdocs/news/status/Makefile
===================================================================
--- head/en_US.ISO8859-1/htdocs/news/status/Makefile
+++ head/en_US.ISO8859-1/htdocs/news/status/Makefile
@@ -84,6 +84,7 @@
 XMLDOCS+=	report-2018-09-2018-12
 XMLDOCS+=	report-2019-01-2019-03
 XMLDOCS+=	report-2019-04-2019-06
+XMLDOCS+=	report-2019-07-2019-09
 
 XSLT.DEFAULT=	report.xsl
 
Index: head/en_US.ISO8859-1/htdocs/news/status/report-2019-07-2019-09.xml
===================================================================
--- head/en_US.ISO8859-1/htdocs/news/status/report-2019-07-2019-09.xml
+++ head/en_US.ISO8859-1/htdocs/news/status/report-2019-07-2019-09.xml
@@ -0,0 +1,3108 @@
+<?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$ -->
+<!-- This file was generated with https://github.com/trasz/md2docbook -->
+<!--
+     Variables to replace:
+     %%START%%     - report month start
+     %%STOP%%      - report month end
+     %%YEAR%%      - 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 %%YEAR%%)
+     %%DUENEXT%%   - next report due date (i.e., June 6)
+-->
+
+<report>
+  <date>
+    <month>07-09</month>
+
+    <year>2019</year>
+  </date>
+
+  <section>
+    <title>Introduction</title>
+<p>Here is the third quarterly status report for 2019.</p>
+
+<p>This quarter the reports team has been more active than usual thanks
+to a better organization: calls for reports and reminders have been
+sent regularly, reports have been reviewed and merged quickly (I would
+like to thank debdrup@ in particular for his reviewing work).</p>
+<p>Efficiency could still be improved with the help of our community.
+In particular, the quarterly team has found that many reports have
+arrived in the last days before the deadline or even after. I would
+like to invite the community to follow the guidelines below that
+can help us sending out the reports sooner.</p>
+<ul>
+<li>Send a first draft of your report when you receive the first call
+for reports (1 month before the deadline).</li>
+<li>Update your report, if needed, when you receive reminders: you will
+normaly receive two (2 weeks and 1 week before the deadline).</li>
+<li>If after the deadline you still have some more updates ask the team
+(either on IRC via #freebsd-wiki or send an email at monthly@) to
+wait for you if you feel that they are urgent, otherwise start
+putting them in a draft for the next quarter.</li></ul>
+
+<p>Starting from next quarter, all quarterly status reports will be
+prepared the last month of the quarter itself, instead of the first
+month after the quarter's end. This means that deadlines for
+submitting reports will be the 1st of January, April, July and
+October.</p>
+<p>Next quarter will then be a short one, covering the months of November
+and December only and the report will probably be out in mid January.</p>
+
+<p>-- Lorenzo Salvadore</p>
+  </section>
+
+  <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>bin</name>
+
+    <description>Userland Programs</description>
+
+    <p>Changes affecting the base system and programs in it.</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>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>
+
+  <project cat='team'>
+    <title>FreeBSD Core Team</title>
+
+    <contact>
+      <person>
+	<name>FreeBSD Core Team</name>
+	<email>core@FreeBSD.org</email>
+      </person>
+    </contact>
+
+    <body>
+      <p>The FreeBSD Core Team is the governing body of FreeBSD.</p>
+
+      <ul>
+	<li>Core has provisionally accepted the BSD+patent license for
+	use in some cases.
+	The Core Team must approve the import of new BSD+Patent
+	licensed components or
+	the change of license of existing components to the
+	BSD+Patent License.
+      <br/>
+	https://opensource.org/licenses/BSDplusPatent</li>
+
+	<li>Kernel Pseudo Random Number Generator (PRNG)
+	maintainership was updated to
+	reduce the contribution barrier for committers who have
+	demonstrated
+	competence in this part of the tree.</li>
+	<li>Core approved a source commit bit for Paweł Biernacki.
+	Konstantin Belousov
+	&lt;kib@&gt; will mentor Paweł and Mateusz Guzik
+	&lt;mjg@&gt; will be co-mentor.</li>
+	<li>The Core-initiated Git Transition Working Group met over
+	the last quarter,
+	however a report is still forthcoming. Discussions will
+	continue in the
+	fourth quarter of 2019. There are many issues to resolve
+	including how to
+	deal with contrib/, whether to re-generate hashes in the
+	current Git
+	repository, and how to best implement commit testing.</li>
+      </ul>
+
+    </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/11.3R/announce.html">FreeBSD 11.3-RELEASE announcement</url>
+      <url href="https://www.freebsd.org/releases/12.1R/schedule.html">FreeBSD 12.1-RELEASE schedule</url>
+      <url href="https://download.freebsd.org/ftp/releases/ISO-IMAGES/12.1/">FreeBSD 12.1-RELEASE BETA/RC 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 2019, the FreeBSD Release
+	Engineering team
+	finished the 11.3-RELEASE cycle, with the final release
+	build started on
+	July 5th and the official announcement sent on July 9th.</p>
+
+      <p>FreeBSD 11.3-RELEASE is the fourth release from the
+	<i>stable/11</i> branch,
+	building on the stability and reliability of 11.2-RELEASE.</p>
+
+      <p>The FreeBSD Release Engineering Team also started work on
+	the upcoming
+	12.1-RELEASE, which started September 6th. This release
+	cycle is the
+	first "freeze-less" release from the Subversion
+	repository, and the test bed
+	for eliminating the requirement of a hard code freeze on
+	development branches.
+	Commits to the <i>releng/12.1</i> branch still
+	require explicit approval from
+	the Release Engineering Team, however.</p>
+
+      <p>At present, there have been three BETA builds, and so far,
+	two RC builds, with
+	the final 12.1-RELEASE build scheduled for November 4th.</p>
+
+      <p>Additionally throughout the quarter, several development
+	snapshots builds
+	were released for the <i>head</i> and
+	<i>stable/11</i> branches; snapshots for
+	<i>stable/12</i> were released as well although
+	not during the 12.1-RELEASE cycle.</p>
+
+      <p>Much of this work was sponsored by Rubicon Communications,
+	LLC (Netgate)
+	and the FreeBSD Foundation.</p>
+
+    </body>
+
+  </project>
+
+  <project cat='team'>
+    <title>FreeBSD Security Team</title>
+
+    <contact>
+      <person>
+	<name>Security Team</name>
+	<email>secteam@FreeBSD.org</email>
+      </person>
+    </contact>
+
+    <links>
+      <url href="https://www.freebsd.org/security/">FreeBSD security information</url>
+    </links>
+
+    <body>
+      <p>Several members of the security team met at the Vendor
+	Summit in October to
+	formalize team structure dedicated for architecture and
+	crypto engineering in
+	addition to the existing product security incident
+	response function.</p>
+
+      <p>Since June we have started having fortnightly conference
+	calls to discuss
+	important issues and to collaborate closely on advisories
+	and errata notices in
+	the pipeline.</p>
+
+      <ul>
+	<li>Security advisories sent out in 2019-Q3: 7</li>
+
+	<li>Errata Notices sent out in 2019-Q3: 5</li>
+      </ul>
+
+    </body>
+
+  </project>
+
+  <project cat='team'>
+    <title>Cluster Administration Team</title>
+
+    <contact>
+      <person>
+	<name>Cluster Administration Team</name>
+	<email>clusteradm@FreeBSD.org</email>
+      </person>
+    </contact>
+
+    <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>Change IPv6 address in TWN site.</li>
+
+	<li>Solved hardware issues in KWC site (with hrs@).</li>
+
+	<li>Moved remaining infrastructure from the YSV (Yahoo!) site
+	to NYI (New York Internet) (peter@).</li>
+
+	<ul><li>YSV hosted most of FreeBSD.org between 2000 and 2019.</li></ul>
+
+	<li>Installed new machines for portmgr@ courtesy of the
+	FreeBSD Foundation.</li>
+
+	<li>Resolved outtages (thanks uqs@) with GitHub exporter,
+	Bugzilla and hg-beta (thanks bapt@).</li>
+
+	<li>PowerPC64 servers are online (power8) building pkgs and
+	reference hosts.</li>
+
+	<li>Ongoing systems administration work:</li>
+
+	<ul><li>Creating accounts for new committers.</li>
+
+	<li>Backups of critical infrastructure.</li>
+
+	<li>Keeping up with security updates in 3rd party software.</li></ul>
+      </ul>
+
+      <p>
+	Work in progress:</p>
+
+      <ul>
+	<li>Review the service jails and service administrators
+	operation.</li>
+
+	<li>South Africa Mirror (JINX) in progress.</li>
+
+	<li>NVME issues on PowerPC64 Power9 blocking dual socket
+	machine from being used as pkg builder.</li>
+
+	<li>Drive upgrade test for pkg builders (SSDs) courtesy of the
+	FreeBSD Foundation.</li>
+
+	<li>Boot issues with Aarch64 reference machines.</li>
+
+	<li>New NYI.net sponsored colocation space in Chicago-land
+	area.</li>
+
+	<li>Setup new host for CI staging environment.</li>
+      </ul>
+
+    </body>
+
+  </project>
+
+  <project cat='team'>
+    <title>Continuous Integration</title>
+
+    <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>
+
+    <links>
+      <url href="https://ci.FreeBSD.org">FreeBSD Jenkins Instance</url>
+      <url href="https://artifact.ci.FreeBSD.org/">FreeBSD CI artifact archive</url>
+      <url href="https://wiki.freebsd.org/Jenkins">FreeBSD Jenkins wiki</url>
+      <url href="https://lists.FreeBSD.org/mailman/listinfo/freebsd-testing">freebsd-testing Mailing List</url>
+      <url href="https://github.com/freebsd/freebsd-ci">FreeBSD CI Repository</url>
+      <url href="https://preview.tinyurl.com/y9maauwg">Tickets related to freebsd-testing@</url>
+      <url href="https://wiki.freebsd.org/HostedCI">Hosted CI wiki</url>
+      <url href="https://hackmd.io/@FreeBSD-CI">FreeBSD CI weekly report</url>
+    </links>
+
+    <body>
+      <p>The FreeBSD CI team maintains continuous integration
+	system and related tasks
+	for the FreeBSD project. The CI system regularly checks
+	the committed changes
+	can be successfully built, then performs various tests and
+	analysis of the
+	results. The results from build jobs are archived in an
+	artifact server, for
+	the 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 code or adjust test infrastructure. The details
+	are of these efforts
+	are available in the weekly CI reports.</p>
+
+      <p>We had a testing working group at the <a
+	href="https://wiki.freebsd.org/DevSummit/201909">201909
+	DevSummit</a>
+	lwhsu@ has presented the Testing/CI project status and
+	"how to work with the FreeBSD CI system", slides
+	are available at the DevSummit page.
+	Some contents have been migrated to
+	https://wiki.freebsd.org/Jenkins/Debug , extending
+	is welcomed.</p>
+
+      <p>We continue publishing CI Weekly Report and moved the
+	archive to https://hackmd.io/@FreeBSD-CI</p>
+
+      <p>Work in progress:</p>
+
+      <ul>
+	<li>Collecting and sorting CI tasks and ideas at
+	https://hackmd.io/bWCGgdDFTTK_FG0X7J1Vmg</li>
+
+	<li>Setup the CI stage environment and put the experimental
+	jobs on it</li>
+
+	<li>Extending and publishing the embedded boards testbed</li>
+
+	<li>Implementing automatic tests on bare metal hardware</li>
+
+	<li>Adding drm ports building test against -CURRENT</li>
+
+	<li>Testing and merging pull requests at
+	https://github.com/freebsd/freebsd-ci/pulls</li>
+
+	<li>Planning for running ztest and network stack tests</li>
+
+	<li>Help more 3rd software get CI on FreeBSD through a hosted
+	CI solution</li>
+      </ul>
+
+      <p>
+	Please see freebsd-testing@ related tickets for more WIP
+	information.</p>
+
+    </body>
+
+    <sponsor>
+      The FreeBSD Foundation
+    </sponsor>
+
+  </project>
+
+  <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 and quality
+	assurance 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>
+
+      <p>Partnerships and Commercial User Support
+	We help facilitate collaboration between commercial users
+	and FreeBSD
+	developers. We also meet with companies to discuss their
+	needs and bring
+	that information back to the Project. In Q3, Ed Maste and
+	Deb Goodkin met
+	with a few commercial users in the US. It is not only
+	beneficial for the
+	above, but it also helps us understand some of the
+	applications where
+	FreeBSD is used. We were also able to meet with a good
+	number of commercial
+	users at vBSDCon and EuroBSDCon. These venues provide an
+	excellent
+	opportunity to meet with commercial and individual users
+	and contributors
+	to FreeBSD.</p>
+
+      <p>Fundraising Efforts
+	Our work is 100% funded by your donations. We are
+	continuing to work hard
+	to get more commercial users to give back to help us
+	continue our work
+	supporting FreeBSD. More importantly, we'd like to thank
+	our individual
+	donors for making $10-$1,000 donations last quarter, for
+	more than $16,000!</p>
+
+      <p>Please consider
+	<a href="https://www.FreeBSDfoundation.org/donate/">making
+	a donation</a> to help us
+	continue and increase our support for FreeBSD!</p>
+
+      <p>We also have the Partnership Program, to provide more
+	benefits for our
+	larger commercial donors. Find out more information at
+	<a
+	href="https://www.FreeBSDfoundation.org/FreeBSD-foundation-partnership-program/">www.FreeBSDfoundation.org/FreeBSD-foundation-partnership-program/</a>
+	and share with your companies.</p>
+
+      <p>OS Improvements
+	The Foundation supports software development projects to
+	improve the FreeBSD
+	operating system through our full time technical staff,
+	contractors, and
+	project grant recipients. They maintain and improve
+	critical kernel
+	subsystems, add new features and functionality, and fix
+	problems.</p>
+
+      <p>Over the last quarter there were 345 commits to the
+	FreeBSD base system
+	repository sponsored by the FreeBSD Foundation - this
+	represents about
+	one fifth of all commits during this period. Many of these
+	projects have
+	their own entries in this quarterly report (and are not
+	repeated here).</p>
+
+      <p>Foundation staff member Konstantin Belousov committed many
+	improvements to
+	multiple kernel subsystems, as well as low-level 32-bit
+	and 64-bit x86
+	infrastructure. These included fixes for robust mutexes,
+	unionfs, the
+	out of memory (OOM) handler, and per-cpu allocators.</p>
+
+      <p>Additional work included fixes for security issues and
+	introduction and
+	maintenance of vulnerability mitigations, and improving
+	POSIX conformance.</p>
+
+      <p>Ed Maste committed a number of minor security bug fixes
+	and improvements,
+	as well as the first iteration of a tool for editing the
+	mitigation control
+	ELF note. Additional work included effort on build
+	infrastructure and the
+	tool chain.</p>
+
+      <p>Clang's integrated assembler (IAS) is now used more
+	widely, as part of the
+	path to retiring the assembler from GNU binutils 2.17.50.
+	The readelf tool
+	now decodes some additional ELF note information.</p>
+
+      <p>Ed also enabled the Linuxulator (Linux binary support
+	layer) on arm64, and
+	added a trivial implementation of the renameat2 system
+	call (handling common
+	options).</p>
+
+      <p>Mark Johnston added Capsicum support to a number of ELF
+	Tool Chain utilities,
+	and committed a number of other Capsicum kernel and
+	userland fixes.</p>
+
+      <p>Mark worked on a number of changes related to security
+	improvements, including
+	integration and support of the Syzkaller automated system
+	call fuzzer, and
+	fixing issues identified by Syzkaller. Other changes
+	included addressing
+	failures caused by refcount wraparound, improvements to
+	the <tt>prot_max</tt> memory
+	protection. Other work included NUMA, locking, kernel
+	debugging, RISC-V and
+	arm64 kernel improvements.</p>
+
+      <p>Edward Napierala continued working on Linuxulator
+	improvements over the
+	quarter. The primary focus continued to be tool
+	improvements - strace is now
+	more usable for diagnosing issues with Linux binaries
+	running under the
+	Linuxulator. That said, as with previous work a number of
+	issues have been
+	fixed along the way. These are generally minor issues with
+	a large impact -
+	for example, every binary linked against up-to-date glibc
+	previously
+	segfaulted on startup. This is now fixed.</p>
+
+      <p>Continuous Integration and Quality Assurance
+	The Foundation provides a full-time staff member who is
+	working on improving
+	our automated testing, continuous integration, and overall
+	quality assurance
+	efforts.</p>
+
+      <p>During the third quarter of 2019, Foundation staff
+	continued to improve the
+	project's CI infrastructure, worked with contributors to
+	fix the failing build
+	and test cases, and worked with other teams in the Project
+	for their testing
+	needs. We added several new CI jobs and worked on getting
+	the hardware
+	regression testing lab ready.</p>
+
+      <p>Li-Wen Hsu gave presentations "Testing/CI status update"
+	and "How to work with
+	the FreeBSD CI system" at the
+	<a href="https://wiki.freebsd.org/DevSummit/201909">201909
+	DevSummit</a>.
+	Slides are available at the DevSummit page.</p>
+
+      <p>We continue publishing the CI weekly report on the
+	<a
+	href="https://lists.freebsd.org/mailman/listinfo/freebsd-testing">freebsd-testing@</a>.
+	mailing list, and an <a
+	href="https://hackmd.io/@freebsd-ci">archive</a>
+	is available.</p>
+
+      <p>See the FreeBSD CI section of this report for completed
+	work items and
+	detailed information.</p>
+
+      <p>Supporting FreeBSD Infrastructure
+	The Foundation provides hardware and support to improve
+	the FreeBSD
+	infrastructure. Last quarter, we continued supporting
+	FreeBSD hardware
+	located around the world.</p>
+
+      <p>FreeBSD Advocacy and Education
+	A large part of our efforts are dedicated to advocating
+	for the Project.
+	This includes promoting work being done by others with
+	FreeBSD; producing
+	advocacy literature to teach people about FreeBSD and help
+	make the path to
+	starting using FreeBSD or contributing to the Project
+	easier; and attending
+	and getting other FreeBSD contributors to volunteer to run
+	FreeBSD events,
+	staff FreeBSD tables, and give FreeBSD presentations.</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.</p>
+
+      <p>Check out some of the advocacy and education work we did
+	last quarter:</p>
+
+      <ul>
+	<li>Sponsored USENIX 2019 Annual Technical Conference as an
+	Industry Partner</li>
+
+	<li>Represented FreeBSD at OSCON 2019 in Portland, OR</li>
+
+	<li>Represented FreeBSD at COSCUP 2019 in Taiwan</li>
+
+	<li>Presented at the Open Source Summit, North American in San
+	Diego, CA</li>
+
+	<li>Executive Director Deb Goodkin was interviewed by TFiR
+	https://www.freebsdfoundation.org/news-and-events/latest-news/tfir-interview-freebsd-meets-linux-at-the-open-source-summit/</li>
+
+	<li>Sponsored FreeBSD Hackathon at vBSDcon 2019 in Reston, VA</li>
+
+	<li>Sponsored the attendee bags and attended vBSDcon 2019 in
+	Reston VA</li>
+
+	<li>Represented FreeBSD at APNIC-48 in Chiang Mai, Thailand</li>
+
+	<li>Represented FreeBSD at MNNOG-1 in Ulaanbaatar, Mongolia</li>
+
+	<li>Served as an administrator for the Project’s Google Summer
+	of Code Session. See the Google Summer of Code
+	section of this report for more information.</li>
+
+	<li>Sponsored FreeBSD Developers Summit at EuroBSDCon in
+	Lillehammer, Norway</li>
+
+	<li>Sponsored and attended EuroBSDcon 2019 in Lillehammer,
+	Norway</li>
+
+	<li>Applied and was accepted for a FreeBSD Miniconf at
+	linux.conf.au, in Gold Coast, Australia, Jan 14,
+	2020</li>
+
+	<li>Our FreeBSD talk was accepted at seaGL, Seattle, WA,
+	November 15 and 16.</li>
+      </ul>
+
+      <p>
+	We continued producing FreeBSD advocacy material to help
+	people promote
+	FreeBSD. Learn more about our recent efforts to advocate
+	for FreeBSD
+	around the world:
+	https://www.freebsdfoundation.org/blog/freebsd-around-the-world/</p>
+
+      <p>Our Faces of FreeBSD series is back. Check out the latest
+	post:
+	<a
+	href="https://www.freebsdfoundation.org/blog/faces-of-freebsd-2019-roller-angel/">Roller
+	Angel</a>.</p>
+
+      <p>Read more about our conference adventures in the
+	conference recaps and trip
+	reports in our monthly newsletters:
+	
+	https://www.freebsdfoundation.org/news-and-events/newsletter/</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
+	<a
+	href="https://www.FreeBSDfoundation.org/news-and-events/">events
+	we attended and upcoming events</a>.</p>
+
+      <p>We opened our official FreeBSD Swag Store. Get stickers,
+	shirts, mugs and
+	more at <a
+	href="https://www.zazzle.com/store/shopfreebsd">ShopFreeBSD</a>.</p>
+
+      <p>We have continued our work with a new website developer to
+	help us improve
+	our website. Work has begun to make it easier for
+	community members to find
+	information and to make the site more efficient.</p>
+
+      <p>Legal/FreeBSD IP
+	The Foundation owns the FreeBSD trademarks, and it is our
+	responsibility to
+	protect them. We also provide legal support for the core
+	team to investigate
+	questions that arise.</p>
+
+      <p>Go to http://www.FreeBSDfoundation.org to find out how we
+	support FreeBSD and
+	how we can help you!</p>
+
+    </body>
+
+  </project>
+
+  <project cat='team'>
+    <title>FreeBSD Graphics Team status report</title>
+
+    <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>
+
+    <links>
+      <url href="https://github.com/FreeBSDDesktop">Project GitHub page</url>
+    </links>
+
+    <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>During the last period, several changes have been made,
+	but most of them has
+	been behind the scene.
+	We have also worked on general clean up of old xorg ports
+	that have been
+	deprecated upstream.</p>
+
+      <p>The ports infrastructure for xorg ports and ports that
+	depend on xorg ports have
+	been updated.
+	We have switched <tt>USE_XORG</tt> and <tt>XORG_CAT</tt>
+	to use the <tt>USES</tt> framework, instead
+	of the old way of including <tt>bsd.xorg.mk</tt> from
+	<tt>bsd.port.mk</tt>.
+	This infrastructure work has been fairly substantial, and
+	new ports depending on
+	xorg ports should add <tt>USES=xorg</tt> to their
+	makefiles.
+	As part of this <tt>bsd.xorg.mk</tt> was split up, and the
+	<tt>XORG_CAT</tt> part was split
+	out to <tt>USES=xorg-cat</tt>.
+	This is used for the xorg ports themselves, and sets up a
+	common environment for
+	building all xorg ports.
+	In addition, framework for pulling xorg ports directly
+	from freedesktop.org
+	gitlab was added, which will make improve development and
+	testing, since it
+	makes it possible to create ports of unreleased versions.
+	Further improvements in this area includes framework for
+	using meson instead of
+	autotools for building xorg ports.
+	This is still a work in progress.</p>
+
+      <p>We have also worked to clean up and deprecate several old
+	xorg ports and
+	libraries.
+	Some of these ports have already been removed, and some
+	are still waiting on
+	removal after a sufficient deprecation period.
+	Most notably amongst the deprecations are
+	<tt>x11/libXp</tt>, which required to fix
+	several dependencies.
+	Several other old libraries have also been deprecated,
+	such as <tt>x11/Xxf86misc</tt>,
+	<tt>x11-fonts/libXfontcache</tt> and
+	<tt>graphics/libGLw</tt>.
+	Some applications and drivers have also been deprecated
+	during the period.
+	With the remaining removals in this area, we should be up
+	to speed with
+	deprecations upstream.
+	We are currently investigating if there are new software
+	added upstream that we
+	need to port to FreeBSD.</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 gitter chat: <a
+	href="https://gitter.im/FreeBSDDesktop/Lobby">https://gitter.im/FreeBSDDesktop/Lobby</a>.
+	We are also available in #freebsd-xorg on EFNet.</p>
+
+      <p>We also have a team area on GitHub where our work
+	repositories can be found:
+	<a
+	href="https://github.com/FreeBSDDesktop">https://github.com/FreeBSDDesktop</a></p>
+
+    </body>
+
+  </project>
+
+  <project cat='proj'>
+    <title>Google Summer of Code 2019</title>
+
+    <contact>
+      <person>
+	<name>Summer of Code Admins</name>
+	<email>soc-admins@freebsd.org</email>
+      </person>
+    </contact>
+
+    <links>
+      <url href="https://wiki.freebsd.org/SummerOfCode2019Projects">2019 Summer of Code Project Wikis</url>
+      <url href="https://summerofcode.withgoogle.com/archive/2019/organizations/6504969929228288/">2019 Summer of Code Projects</url>
+    </links>
+
+    <body>
+      <p>The FreeBSD Project is pleased to have participated in
+	Google Summer of Code 2019 marking our 14th year of
+	participation.
+	This year we had six successful projects:</p>
+
+      <ul>
+	<li><i>Dual-stack ping command</i> by Ján Sučan</li>
+
+	<li><i>Firewall test suite</i> by Ahsan Barkati</li>
+
+	<li><i>Kernel sanitizers</i> by Costin Carabaș</li>
+
+	<li><i>MAC policy on IP addresses for FreeBSD
+	Jail</i> by Shivank Garg</li>
+
+	<li><i>Separation of ports build process from local
+	installation</i> by Theron Tarigo</li>
+
+	<li><i>Virtual memory compression</i> by
+	Paavo-Einari Kaipila</li>
+      </ul>
+
+      <p>
+	We thank Google for the opportunity to work with these
+	students and hope
+	they continue to work with FreeBSD in the future.</p>
+
+    </body>
+
+    <sponsor>
+      Google Summer of Code
+    </sponsor>
+
+  </project>
+
+  <project cat='proj'>
+    <title>GSoC'19 Project - MAC policy on IP addresses in Jail: mac_ipacl</title>
+
+    <contact>
+      <person>
+	<name>Shivank Garg</name>
+	<email>shivank@FreeBSD.org</email>
+      </person>
+    </contact>
+
+    <links>
+      <url href="https://reviews.freebsd.org/D20967">FreeBSD's Phabricator Differential Link</url>
+      <url href="https://github.com/freebsd/freebsd/compare/master...shivankgarg98:shivank_MACPolicyIPAddressJail">Github Diff Link</url>
+      <url href="https://wiki.freebsd.org/SummerOfCode2019Projects/MACPolicyIPAddressJail">Project Wiki Page</url>
+    </links>
+
+    <body>
+      <p><b>About -</b> With the introduction of VNET(9)
+	in FreeBSD, Jails are free to
+	set their IP addresses. However, this privilege may need
+	to be limited by
+	the host as per its need for multiple security reasons.
+	This project uses mac(9) for an access control framework
+	to impose
+	restrictions on FreeBSD jails according to rules defined
+	by the root of the
+	host using sysctl(8). It involves the development of a
+	dynamically loadable
+	kernel module (mac_ipacl) based on The TrustedBSD MAC
+	Framework to
+	implement a security policy for configuring the network
+	stack.
+	This project allows the root of the host to define the
+	policy rules to
+	limit the root of a jail to a set of IP (v4 or v6)
+	addresses and/or subnets
+	for a set of interfaces.</p>
+
+      <p>Features this new MAC policy module are:</p>
+
+      <ul>
+	<li>The host can define one or more lists of IP
+	addresses/subnets
+      	for the jail to choose from.</li>
+
+	<li>The host can restrict the jail from setting certain IP
+	addresses or
+      	prefixes (subnets).</li>
+
+	<li>The host can restrict this privilege to a few network
+	interfaces.</li>
+      </ul>
+
+      <p>
+	<b>Implementation -</b> The mac_ipacl module is
+	a loadable kernel module. It
+	implements mac checks in netinet/in.c and netinet6/in6.c
+	to check the IP
+	addresses requested by jail. The idea to implement these
+	checks at these
+	places comes from the fact that SIOCAIFADDR (for IPv4) and
+	SIOCAIFADDR_IN6 (for IPv6) ioctl handlers are defined for
+	adding the IP
+	addresses to an interface. This is used by ifconfig (in
+	userspace) for
+	setting the IP address. The MAC Framework acts as
+	multiplexer between the
+	netinet and the module. The requested IP and the
+	credentials are checked
+	with the rules in mac_ipacl and output is returned
+	accordingly to netinet.
+	The module can be tuned with various sysctl and similarly,
+	policy rules are
+	also be defined with sysctl.</p>
+
+      <p><b>TestSuite -</b> Test scripts integrated with
+	kyua and ATF are included with
+	the module.</p>
+
+      <p><b>Using the module -</b> I have written a man
+	page for the module. Please
+	refer to the mac_ipacl(4) for using the new MAC module and
+	various examples.</p>
+
+      <p><b>Final Deliverables -</b></p>
+
+      <ul>
+	<li>A loadable kernel module - <a
+	href="https://github.com/shivankgarg98/freebsd/tree/shivank_MACPolicyIPAddressJail/sys/security/mac_ipacl">mac_ipacl
+	in sys/security/mac_ipacl</a></li>
+	<li>ATF tests for the module in <a
+	href="https://github.com/shivankgarg98/freebsd/tree/shivank_MACPolicyIPAddressJail/tests/sys/mac/ipacl">tests/sys/mac/ipacl</a></li>
+	<li>A man page for this new mac module - mac_ipacl.4 in
+	<a
+	href="https://github.com/shivankgarg98/freebsd/blob/shivank_MACPolicyIPAddressJail/share/man/man4/mac_ipacl.4">share/man/man4/mac_ipacl.4</a></li>
+      </ul>
+
+      <p>This is a new project, developed as part of <b>Google
+	Summer of Code'19</b>
+	under the guidance of <b>Bjoern A. Zeeb</b>
+	&lt;<a href="mailto:bz@FreeBSD.org">bz@FreeBSD.org</a>&gt;. The module is
+	<b>reviewed</b> and <b>Revision for this project
+	is accepted and ready to
+	land</b>. It is yet to be merged with FreeBSD HEAD, and
+	waiting to be tested
+	by few more hands in the industry.</p>
+
+      <p>I'll be very thankful if you can give this module a try
+	and share your
+	valuable experience about it. Please be free to share your
+	ideas and
+	feedback on this module and please do not hesitate to send
+	me an email.</p>
+
+    </body>
+
+  </project>
+
+  <project cat='proj'>
+    <title>FUSE</title>
+
+    <contact>
+      <person>
+	<name>Alan Somers</name>
+	<email>asomers@FreeBSD.org</email>
+      </person>
+    </contact>
+
+    <body>
+      <p>FUSE (File system in USErspace) allows a userspace program
+	to
+	implement a file system. It is widely used to support
+	out-of-tree file
+	systems like NTFS, as well as for exotic pseudo file
+	systems like
+	sshfs. FreeBSD's fuse driver was added as a GSoC project
+	in 2012.
+	Since that time, it has been largely neglected. The FUSE
+	software is
+	<a
+	href="https://bugs.freebsd.org/bugzilla/buglist.cgi?bug_status=__open__&amp;known_name=fusefs&amp;list_id=289348&amp;query_based_on=fusefs&amp;query_format=advanced&amp;short_desc=%5Bfusefs%5D%20sysutils%2Ffusefs-&amp;short_desc_type=anywordssubstr">buggy</a>
+	and out-of-date. Our implementation is about 11 years
+	behind.</p>
+
+      <p>I completed this work during Q3. I fixed a few
+	newly-introduced bugs, fixed a
+	long-standing sendfile bug that affects FUSE
+	
+	([236466](https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236466))
+	and merged
+	everything to head and stable/12. Then I fixed the
+	resulting Coverity CIDs.
+	There have been no new FUSE-related bug reports, so I can
+	only assume that
+	everything is working great. Report any problems to
+	asomers@FreeBSD.org.</p>
+
+    </body>
+
+    <sponsor>
+      The FreeBSD Foundation
+    </sponsor>
+
+  </project>
+
+  <project cat='proj'>
+    <title>NFS Version 4.2 implementation</title>
+
+    <contact>
+      <person>
+	<name>Rick Macklem</name>
+	<email>rmacklem@freebsd.org</email>
+      </person>
+    </contact>
+
+    <body>
+      <p>RFC-7862 describes a new minor revision to the NFS Version
+	4 protocol.
+	This project implements this new minor revision.</p>
+
+      <p>The NFS Version 4 Minor Version 2 protocol adds several
+	optional
+	features to NFS, such as support for SEEK_DATA/SEEK_HOLE,
+	file
+	copying done on the server that avoids data transfer over
+	the wire
+	and support for posix_fallocate(), posix_fadvise().
+	Hopefully these features can improve performance for
+	certain applications.</p>
+
+      <p>The implementation is now nearing completion and recent
+	work has been
+	mostly testing. A cycle of interoperability testing with
+	Linux has
+	just been completed. The main area that still needs
+	testing is use
+	of the pNFS server with NFSv4.2 and that should start
+	soon.
+	Once testing of pNFS is completed, I believe the code is
+	ready to
+	be incorporated into FreeBSD head/current.</p>
+
+      <p>Testing by others would be appreciated. The modified
+	kernel can be
+	found at https://svn.freebsd.org/base/projects/nfsv42/sys
+	and should
+	run with a recent FreeBSD head/current system. Client
+	mounts need the
+	"minorversion=2" mount option to enable this protocol.</p>
+
+    </body>
+
+  </project>
+
+  <project cat='proj'>
+    <title>FAT / msdosfs support for makefs(8)</title>
+
+    <contact>
+      <person>
+	<name>Ed Maste</name>
+	<email>emaste@FreeBSD.org</email>
+      </person>
+    </contact>
+
+    <body>
+      <p>In order to streamline the process of creating install or
+	virtual
+	machine system images we needed FAT filesystem support in
+	makefs(8).
+	Makefs was originally developed in NetBSD, and FAT support
+	was added
+	there not much later, but after the tool was ported to
+	FreeBSD.</p>
+
+      <p>Siva Mahadevan, one of the FreeBSD Foundation's interns
+	from the
+	University of Waterloo, worked on porting FAT support from
+	NetBSD.
+	I <a href="https://reviews.freebsd.org/D16438">rebased and
+	updated</a> Siva's
+	work, and <a
+	href="https://reviews.freebsd.org/rS351273">committed</a>
+	it during
+	this quarter. After a few follow-up fixes we are able to
+	build FAT
+	filesystem images without using md(4) and without
+	requiring root.</p>
+
+    </body>
+
+    <sponsor>
+      The FreeBSD Foundation
+    </sponsor>
+
+  </project>
+
+  <project cat='proj'>
+    <title>syzkaller on FreeBSD</title>
+
+    <contact>
+      <person>
+	<name>Andrew Turner</name>
+	<email>andrew@FreeBSD.org</email>
+      </person>
+      <person>
+	<name>Mark Johnston</name>
+	<email>markj@FreeBSD.org</email>
+      </person>
+      <person>
+	<name>Michael Tuexen</name>
+	<email>tuexen@FreeBSD.org</email>
+      </person>
+      <person>
+	<name>Samy Al Bahra</name>
+	<email>sbahra@freebsd.org</email>
+      </person>
+    </contact>
+
+    <body>
+      <p>See the syzkaller entry in the 2019q1 quarterly report for
+	an
+	introduction to syzkaller.</p>
+
+      <p>Work has continued on fixing bugs uncovered by syzkaller.
+	Over a dozen
+	kernel bugs fixed in the past three months have been
+	directly attributed
+	to syzkaller, and a number of syzkaller reproducers have
+	been
+	incorporated into our test suite.</p>
+
+      <p>backtrace.io, via Samy, has graciously provided a large
+	server for
+	running a dedicated syzkaller instance to fuzz FreeBSD
+	under bhyve.
+	Though syzbot, the public syzkaller instance run by
+	Google, already
+	fuzzes FreeBSD, it has proven fruitful to run multiple
+	syzkaller
+	instances: different instances find different bugs, and
+	syzkaller.backtrace.io allows us to experiment with
+	FreeBSD-specific
+	extensions. In particular, this instance currently uploads
+	data about
+	each crash to backtrace.io, making it much easier to
+	triage and analyze
+	crashes. We plan to make this service generally available
+	to FreeBSD
+	developers in the near future.</p>
+
+      <p>Going forward we will continue to extend syzkaller
+	coverage and make it
+	simpler for users and developers to run private instances,
+	and
+	optionally collect kernel crash information for debugging
+	or for
+	submission.</p>
+
+    </body>
+
+    <sponsor>
+      backtrace.io
+    </sponsor>
+
+    <sponsor>
+      The FreeBSD Foundation
+    </sponsor>
+
+  </project>
+
+  <project cat='proj'>
+    <title>Rockchip RK3399 SoC's eMMC support</title>
+
+    <contact>
+      <person>
+	<name>Ganbold Tsagaankhuu</name>
+	<email>ganbold@FreeBSD.org</email>
+      </person>
+    </contact>
+
+    <body>
+      <p>The followings features have been added to support RK3399
+	SoC eMMC on FreeBSD:</p>
+
+      <ul>
+	<li>Extended simple_mfd driver to expose a syscon interface if
+	that node is also compatible with syscon. For instance,
+	Rockchip RK3399's GRF (General Register Files) is
+	compatible
+	with simple-mfd as well as syscon and has devices like
+	usb2-phy, emmc-phy and pcie-phy etc. under it.</li>
+
+	<li>Made Rockchip's General Register Files driver the subclass
+	of Simple MFD driver</li>
+
+	<li>Added driver for Rockchip RK3399 eMMC PHY.</li>
+
+	<li>Added eMMC support codes for Rockchip RK3399 SoC.</li>
+
+	<li>All above was tested on NanoPC-T4 board.</li>
+      </ul>
+
+    </body>
+
+  </project>
+
+  <project cat='proj'>
+    <title>TPM2 Software Stack (TSS2)</title>
+
+    <contact>
+      <person>
+	<name>D Scott Phillips</name>
+	<email>scottph@FreeBSD.org</email>
+      </person>
+    </contact>
+
+    <links>
+      <url href="https://tpm2-tss.readthedocs.io/en/latest/index.html">tpm2-tss Documentation</url>
+      <url href="https://github.com/tpm2-software/">tpm2 Source Repository</url>
+      <url href="https://lists.01.org/postorius/lists/tpm2.lists.01.org/">tpm2 mailing list</url>
+      <url href="ircs://chat.freenode.net:6697/tpm2.0-tss">tpm2 irc channel</url>
+    </links>
+
+    <body>
+      <p>Intel has contributed ports of the TPM2 Software Stack to
+	the ports tree, with
+	the new ports securtity/tpm2-tss, security/tpm2-tools,
+	security/tpm2-abrmd.
+	<tt>tpm2-tss</tt> contains a set of libraries which expose
+	various TPM2 APIs for using
+	a TPM conforming to the TCG TPM 2.0 specification.
+	<tt>tpm2-tools</tt> provides a set
+	of command line tools which use the <tt>tpm2-tss</tt>
+	libraries to perform tpm
+	operations. Finally, <tt>tpm2-abrmd</tt> is a userspace
+	daemon which acts as a TPM
+	Access Broker and Resource Manager, multiplexing many TPM
+	users onto a single
+	TPM device.</p>
+
+      <p>Sponsored by: Intel Corporation</p>
+
+    </body>
+
+  </project>
+
+  <project cat='proj'>
+    <title>Improving laptop support</title>
+
+    <contact>
+      <person>
+	<name>Ed Maste</name>
+	<email>emaste@FreeBSD.org</email>
+      </person>
+    </contact>
+
+    <body>
+      <p>The FreeBSD Foundation would like to ensure that running
+	FreeBSD on
+	contemporary hardware, including laptops, remains viable.
+	To that end
+	we plan to purchase the latest generation of one or more
+	of a family
+	of laptops preferred by members of the FreeBSD community,
+	evaluate the
+	existing state of hardware support, and implement missing
+	hardware
+	support where possible.</p>
+
+      <p>As the first laptop for this project we have selected a
+	7th Generation
+	Lenovo X1 Carbon.</p>
+
+    </body>
+
+    <sponsor>
+      The FreeBSD Foundation
+    </sponsor>
+
+  </project>
+
+  <project cat='bin'>
+    <title>gets(3) retirement</title>
+
+    <contact>
+      <person>
+	<name>Ed Maste</name>
+	<email>emaste@FreeBSD.org</email>
+      </person>
+    </contact>
+
+    <body>
+      <p>gets is an obsolete C library routine for reading a string
+	from standard
+	input. It was removed from the C standard as of C11
+	because there was no
+	way to use it safely. Prompted by a comment during Paul
+	Vixie's talk at
+	vBSDCon 2017 I started investigating what it would take to
+	remove gets
+	from libc.</p>
+
+      <p><a href="https://reviews.freebsd.org/D12298">The patch</a>
+	was posted to Phabricator
+	and refined several times, and the portmgr team performed
+	several
+	<a href="https://bugs.freebsd.org/222796">exp-runs</a> to
+	identify ports broken by
+	the removal. Symbol versioning is used to preserve binary
+	compatibility
+	for existing software that uses gets.</p>
+
+      <p>The change was <a
+	href="https://reviews.freebsd.org/rS351659">committed</a>
+	in
+	September, and will be in FreeBSD 13.0.</p>
+
+    </body>
+
+    <sponsor>
+      The FreeBSD Foundation
+    </sponsor>
+
+  </project>
+
+  <project cat='kern'>
+    <title>Kernel Mapping Protections</title>
+
+    <contact>
+      <person>
+	<name>Mark Johnston</name>
+	<email>markj@FreeBSD.org</email>
+      </person>
+    </contact>
+
+    <body>
+      <p>Modern CPU architectures have the ability to flag memory
+	mappings as
+	"no-execute" (NX), which prevents that memory from being
+	executed by a
+	processor. NX mappings are an important security
+	mitigation since they help
+	segregate code and data, blocking unintentional execution
+	of memory whose
+	contents is controlled by an attacker. W^X (write XOR
+	execute) is a security
+	policy which disallows the creation of mappings that are
+	simultaneously
+	writeable and executable. Under this policy, memory whose
+	contents can be
+	modified must be mapped with the NX flag. This policy
+	makes it harder to exploit
+	bugs that permit an attacker to arbitrarily overwrite
+	data.</p>
+
+      <p>FreeBSD has long made use of the NX flag for userspace
+	mappings whenever
+	possible, but only in the past several years has it been
+	applied to kernel
+	mappings. A recent project has sought to implement a
+	W^X-by-default policy for
+	the amd64 kernel by completing an audit of the remaining
+	executable mappings in
+	the kernel, and making modifications to either apply the
+	NX bit to those
+	mappings or to make them read-only. This work has landed
+	in HEAD and will be
+	available in FreeBSD 13.0 and 12.2. Similar work for other
+	CPU architectures is
+	also planned.</p>
+
+      <p>To help audit kernel mapping protections, the
+	vm.pmap.kernel_maps sysctl was
+	added; it dumps a snapshot of the kernel's page table
+	entries and their
+	attributes. This way, mappings violating the W^X policy
+	can easily be
+	discovered and investigated, and the sysctl provides
+	information useful to
+	anyone interested in kernel memory layout.</p>
+
+      <p>With a few rare exceptions, the only kernel mappings which
+	require execute
+	permission are those of the kernel executable itself, and
+	loadable kernel
+	modules. A number of other regions of memory were
+	unnecessarily being mapped
+	without NX, and these were identified and corrected first.
+	To address the
+	kernel code mappings, the amd64 kernel linker script was
+	modified to pad the
+	.text segment to a 2MB boundary. To improve performance,
+	the kernel creates
+	superpage mappings of its .text segment, but this means
+	that any data cohabiting
+	the final 2MB .text mapping is mapped with execute
+	permissions. The padding
+	allows executable code to be segregated from data which
+	follows in the kernel
+	image, avoiding this problem and maintaining the superpage
+	optimization at the
+	expense of some wasted RAM.</p>
+
+      <p>Enforcing W^X turned out to be somewhat trickier. Unlike
+	other CPU
+	architectures supported by FreeBSD, amd64 kernel modules
+	are linked as
+	relocatable object files, i.e., .o files. (On other
+	architectures, they are
+	dynamically shared objects (DSOs, or .so files), as one
+	might naively expect.)
+	The use of .o files means that amd64 kernel modules
+	contain more efficient code
+	than they would if linked as DSOs, since DSOs inherently
+	make use of certain
+	types of indirection which allow shared libraries to be
+	loaded at arbitrary
+	addresses, and this indirection is useless in the kernel.
+	As part of this
+	project an attempt was made to switch amd64 to using DSOs
+	as well, since the
+	cost of this indirection can largely be mitigated with
+	modern toolchains, but it
+	was found that the use of DSOs would also force a change
+	to the code model used
+	when compiling amd64 kernel code, resulting in a further
+	performance penalty.</p>
+
+      <p>The main obstacle with the use of .o files is that
+	sections are not page-aligned
+	by default; the segregation of sections with differing
+	mapping protection
+	requirements is done by the static linker when linking a
+	DSO or executable file.
+	Since mapping protections are applied at the granularity
+	of the page size (4KB
+	on amd64), the overlap of sections within a page causes
+	problems since, for
+	example, the end of the read-only .text section may
+	overlap with the beginning
+	of the read-write .data section. One possible solution is
+	to perform any
+	required section reordering and padding at kernel module
+	load time, but this
+	approach breaks debugging tools such as dtrace(1) and kgdb
+	which assume that the
+	kernel linker does not modify the layout of loadable
+	modules. As a result, an
+	amd64 kernel module linker script is now used to insert
+	padding for specific
+	sections. Finally, the kernel linker was modified to
+	restrict mapping
+	protections based on section flags.</p>
+
+      <p>As a result of all of this, amd64 kernels now boot without
+	any writeable,
+	executable mappings. Though some of the work was
+	architecture-specific, much of
+	it can and will be leveraged to provide the same policy
+	for our other supported
+	architectures.</p>
+
+    </body>
+
+    <sponsor>
+      Netflix
+    </sponsor>
+
+  </project>
+
+  <project cat='kern'>
+    <title>PROT_MAX mmap/mprotect maximum protections API</title>
+
+    <contact>
+      <person>
+	<name>Brooks Davis</name>
+	<email>brooks@freebsd.org</email>
+      </person>
+    </contact>
+
+    <links>
+      <url href="https://reviews.freebsd.org/rS349240">PROT_MAX commit</url>
+    </links>
+
+    <body>
+      <p>Unix-like systems provide the <tt>mmap(2)</tt> system call
+	to allocate memory or
+	map files or devices into memory with specified access
+	protection, and the
+	<tt>mprotect(2)</tt> system call to change protections on
+	mapped memory. Protection
+	flags specify whether the memory may be read, written,
+	and/or executed
+	(<tt>PROT_READ</tt>, <tt>PROT_WRITE</tt>, <tt>PROT_EXEC</tt>
+	respectively). Traditionally,
+	<tt>mprotect(2)</tt> can be used to set any desired
+	protections (except that a
+	shared mapping of a file opened read-only cannot have
+	<tt>PROT_WRITE</tt> set).</p>
+
+      <p>A new macro <tt>PROT_MAX()</tt> adds a facility for
+	specifying the maximum possible
+	protection flags for <tt>mmap(2)</tt> and
+	<tt>mprotect(2)</tt> calls. The program can then
+	specify whether a mapping may be changed in the future to
+	allow a given access
+	protection. For example, a memory mapping can be set such
+	that it can have
+	read and write protections set, but may never be made
+	executable.</p>
+
+      <p>Maximum protection values are provided to the
+	<tt>PROT_MAX()</tt> macro, and are
+	OR'd with regular protection values.</p>
+
+      <p>This change allows (e.g.) a region that must be writable
+	during run-time
+	linking or JIT code generation to be made permanently
+	read+execute after
+	writes are complete. This complements Write-XOR-Execute
+	(W^X) protections
+	available on other operating systems, allowing more
+	precise control by the
+	programmer.</p>
+
+      <p>For example, to request memory that cannot be made
+	executable:
+	<ttt>
+	mmap(NULL, size, PROT_READ | PROT_WRITE |
+	PROT_MAX(PROT_READ | PROT_WRITE),
+	MAP_ANON, -1, 0);
+	</ttt></p>
+
+      <p>and to request memory that may have execute permission
+	enabled later on, but
+	is not currently executable:</p>
+
+      <p><ttt>
+	mmap(NULL, size,
+	PROT_READ | PROT_WRITE | PROT_MAX(PROT_READ | PROT_WRITE |
+	PROT_EXECUTE),
+	MAP_ANON, -1, 0);
+	</ttt></p>
+
+      <p>This change alters mprotect argument checking and returns
+	an error when
+	unhandled protection flags are set. This differs from
+	POSIX (in that POSIX
+	only specifies an error if a valid permission can not be
+	set), but is the
+	documented behavior on Linux and more closely matches
+	historical mmap behavior.</p>
+
+      <p>In addition to explicit setting of the maximum
+	permissions, an experimental
+	sysctl <tt>vm.imply_prot_max</tt> causes mmap to assume
+	that the initial permissions
+	requested should be the maximum when the sysctl is set to
+	1. This behavior is
+	known to break code that uses <tt>PROT_NONE</tt>
+	reservations before mapping contents
+	into part of the reservation. A later version of this work
+	is expected to
+	provide per-binary and per-process opt-in/out options and
+	this sysctl may be
+	removed in its current form. As such it is undocumented.</p>
+
+      <p>While these flags are non-portable, they can be used in
+	portable code with
+	simple ifdefs to expand <tt>PROT_MAX()</tt> to 0.</p>
+
+      <p>Sponsors: DARPA, AFRL</p>
+
+    </body>
+
+  </project>
+
+  <project cat='kern'>
+    <title>Kernel ZLIB Update</title>
+
+    <contact>
+      <person>
+	<name>Xin Li</name>
+	<email>delphij@FreeBSD.org</email>
+      </person>
+      <person>
+	<name>Yoshihiro Ota</name>
+	<email>ota@j.email.ne.jp</email>
+      </person>
+    </contact>
+
+    <body>
+      <p>The ZLIB is a compression library is widely used in
+	various software.
+	The FreeBSD system had used an ancient (over 20 year-old)
+	version
+	of zlib (version 1.0.4) and total of 3 versions, one in
+	user-land,
+	one in ZFS, and one in kernel.
+	Xin and Yoshihiro upgraded zlib to the latest and
+	eliminated 2 extra copies.
+	Along the efforts, zlib version was upgraded to 1.2.11,
+	netgraph's ppp is
+	re-implemented to use the standard zlib, and removed
+	unmaintained code.
+	We now only have one and the latest version of zlib in
+	FreeBSD code base,
+	new compress, compress2, and uncompress APIs exposed in
+	the kernel,
+	and importing changes from zlib will be simple.</p>
+
+      <p>Kernel zlib changes</p>
+
+      <ul>
+	<li><a href="https://reviews.freebsd.org/D20193">sys/crc32.h
+	is split to avoid object file name conflict with
+	ZLIB's</a></li>
+
+	<li><a href="https://reviews.freebsd.org/D20191">contrib/zlib
+	is moved to sys/contrib/zlib</a></li>
+
+	<li><a href="https://reviews.freebsd.org/D19706">Kernel
+	started switching to sys/contrib/zlib and ZFS copy
+	dropped</a></li>
+
+	<li><a href="https://reviews.freebsd.org/D21156">Kernel
+	zcalloc is introduced and compress, compress2, and
+	uncompress APIs are exposed to kernel</a></li>
+
+	<li><a href="https://reviews.freebsd.org/D21375">Removed zlib
+	1.0.4 from kernel</a></li>
+      </ul>
+
+      <p>
+	Kernel zlib user updates</p>
+
+      <ul>
+	<li><a href="https://reviews.freebsd.org/D21176">kern_ctf.c
+	updated</a></li>
+
+	<li><a
+	href="https://reviews.freebsd.org/D20222">opencryptodeflate
+	updated</a></li>
+
+	<li><a href="https://reviews.freebsd.org/D20271">geom_uzip
+	updated</a></li>
+
+	<li><a
+	href="https://reviews.freebsd.org/D21408">subr_compressor
+	updated</a></li>
+
+	<li><a href="https://reviews.freebsd.org/D20272">if_mxge
+	updated</a></li>
+
+	<li><a href="https://reviews.freebsd.org/D21175">bxe
+	updated</a></li>
+
+	<li><a href="https://reviews.freebsd.org/D21186">ng_deflate
+	updated</a></li>
+      </ul>
+
+      <p>
+	Legacy code removals</p>
+
+      <ul>
+	<li><a href="https://reviews.freebsd.org/D20190">Removed MIPS
+	zlib elf trampoline</a></li>
+
+	<li><a href="https://reviews.freebsd.org/D20248">Removed kgzip
+	and kgzldr</a></li>
+
+	<li><a href="https://reviews.freebsd.org/D21099">Removed
+	gzip'ed a.out support</a></li>
+
+	<li><a href="https://reviews.freebsd.org/D21072">Removed ArmvX
+	elf_trampoline.c</a></li>
+      </ul>
+
+    </body>
+
+  </project>
+
+  <project cat='kern'>
+    <title>Casueword(9) livelock</title>
+
+    <contact>
+      <person>
+	<name>Konstantin Belousov</name>
+	<email>kib@FreeBSD.org</email>
+      </person>
+    </contact>
+
+    <body>
+      <p>The Compare-And-Swap (CAS) is one of the fundamental
+	building blocks
+	for hardware-assisted atomic read/modify/write operations.
+	Some
+	architectures support it directly, for instance x86 and
+	sparc. Others
+	provide different building blocks, usually the pair of
+	Load
+	Linked/Store Conditional instructions (ll/sc) which can be
+	used to construct
+	CAS or other atomic operations like Fetch-And-Add or any
+	atomic
+	arithmetic ops using plain arithmetic instructions. An
+	example is the
+	LDXR/STXR pair on AArch64.</p>
+
+      <p>The ll/sc operation is performed by first using the load
+	linked
+	instruction to load a value from memory and simultaneously
+	mark the
+	cache line for exclusive access. The value is then updated
+	by the
+	store conditional instruction, but only if there were not
+	any writes to
+	the marked cache line. Any write by another CPU makes the
+	store
+	instruction fail. So typically atomic primitives on ll/sc
+	architectures retry the whole operation if only store
+	failed, because
+	it just means that this CPU either lost a race, or even
+	the failure
+	was spurious. This is so called strong version of CAS and
+	atomics.
+	If primitive returns failure instead, the CAS variant is
+	called weak
+	by C standard.</p>
+
+      <p>For the FreeBSD threading library lock implementation,
+	when the fast path
+	mode in userspace was not possible, the kernel often needs
+	to do a CAS
+	operation on user memory location. In addition to all
+	guarantees of
+	normal CAS, it also must ensure the safety and tolerance
+	to paging.
+	In FreeBSD, the casueword32(9) primitive provides CAS on
+	usermode
+	32bit words for kernel. Casueword32(9) was implemented as
+	strong CAS,
+	similarly to the mode of operation of hardware CAS
+	instructions on
+	x86.</p>
+
+      <p>Using the strong implementation for casueword may be
+	dangerous,
+	since the same address is potentially accessible to other,
+	potentially
+	malicious, threads in the same or other processes. If
+	such a thread constantly dirties the cache line used by a
+	ll/sc loop, it
+	could practically force the kernel-mode thread to remain
+	stuck in the loop
+	forever. Since the loop is tight, and it does not check
+	for signals,
+	the thread cannot be stopped or killed.</p>
+
+      <p>The solution is to make the casueword implementation weak,
+	which means that
+	the interface of the primitive must be changed to allow
+	notifying the
+	caller about spurious failures. Also, it is now the
+	caller's responsibility
+	to retry as appropriate.</p>
+
+      <p>The change to casueword was made for all architectures.
+	Even on x86,
+	the PSL.ZF value after the CMPXCHG instruction was
+	returned directly
+	for the new casueword. All two dozens uses of the
+	primitive, all
+	located in <i>kern_umtx.c</i>, were inspected
+	and retry added as needed.</p>
+
+      <p>As a somewhat related note, in-kernel
+	<tt>atomic_cmpset(9)</tt> operations are
+	strong, while <tt>atomic_fcmpset(9)</tt> should be weak,
+	unless broken by
+	a specific architecture. The general attitude seems to be
+	that retry is the
+	duty of the primitive's caller.</p>
+
+    </body>
+
+    <sponsor>
+      The FreeBSD Foundation
+    </sponsor>
+
+  </project>
+
+  <project cat='kern'>
+    <title>Signals delivered on unhandled Page Faults</title>
+
+    <contact>
+      <person>
+	<name>Konstantin Belousov</name>
+	<email>kib@FreeBSD.org</email>
+      </person>
+    </contact>
+
+    <body>
+      <p>By necessity, handling of page faults is separated into
+	two pieces. The
+	first is the architecture-dependent low-level machine
+	exception handler,
+	and the second is the architecture-independent
+	<tt>vm_fault()</tt> function in
+	<i>sys/vm/vm_fault.c</i>.</p>
+
+      <p>Machine-dependent code for page faults typically consists
+	of three
+	components: a trampoline written in assembly which creates
+	the C execution
+	environment and gathers hardware-supplied data about page
+	fault reason, a
+	<tt>trap()</tt> function which is common C-level entry
+	point to dispatch all
+	exceptions processing, and the <tt>trap_pfault()</tt> C
+	function to specifically
+	handle page faults. <tt>trap_pfault()</tt> calls
+	<tt>vm_fault()</tt> when help from VM is
+	needed to resolve the situation.</p>
+
+      <p>If the fault was handled either by
+	<tt>trap()</tt>/<tt>trap_pfault()</tt> or
+	<tt>vm_fault()</tt>,
+	the faulting instruction is restarted. If fault cannot be
+	handled for
+	any reason, the next action depends on the mode in which
+	the fault occured.
+	If it was in kernel, and the kernel installed a helper,
+	then the helper is
+	called instead of returning to the faulting instruction.
+	Otherwise,
+	a kernel-mode page fault causes a panic.</p>
+
+      <p>If the unhandled fault occured in usermode, then all
+	Unixes send a
+	signal to the thread whose execution caused the exception.
+	POSIX (or
+	Single Unix Specification) lists several cases where a
+	signal should be
+	sent, and specifies the signal number and <tt>si_code</tt>
+	from siginfo that
+	must be supplied with the signal.</p>
+
+      <p>Unfortunately, FreeBSD was rather non-compliant in this
+	regard. A long
+	time ago, to improve compliance, we changed the signal
+	sent on access
+	to a page with permissions incompatible with the access
+	mode.
+	That caused multiple problems with garbage collection
+	(GC)-based runtimes
+	which incorporated knowledge of the FreeBSD quirks, so the
+	<tt>machdep.prot_fault_translation</tt> sysctl knob was
+	added. More cases of
+	incompatibility were identified recently.</p>
+
+      <p>Part of the problem is that code to calculate the signal
+	and <tt>si_code</tt> from
+	the Mach error returned by <tt>vm_fault()</tt> was located
+	in <tt>trap_pfault()</tt>. In
+	other words, each architecture did that on its own, with a
+	specific set
+	of bugs and non-compliance. Sometimes code even
+	mis-interpreted returned
+	Mach errors as <tt>errno</tt>.</p>
+
+      <p>A new helper function <tt>vm_fault_trap()</tt> was added,
+	that does several
+	things for trap handlers: it creates ktrace points for
+	faults, calls
+	<tt>vm_fault()</tt>, and then interprets the result in
+	terms of the user-visible
+	error condition, returning precalculated signal number and
+	<tt>si_code</tt> to
+	the caller. Now <tt>trap_pfault()</tt> only needs to
+	provide signal numbers
+	for truly machine-dependent errors. For amd64, an example
+	of such a
+	case is a protection key violation.</p>
+
+      <p>Besides compliance and bug fixes, we also provided some
+	refinements to
+	userspace about the reason of the delivered signal. For
+	instance, on
+	SIGBUS caused by copy-on-write failure due to exceeding
+	swap
+	reservation limit, we provide specific <tt>si_code</tt>
+	<tt>BUS_OOMERR</tt>.</p>
+
+    </body>
+
+    <sponsor>
+      The FreeBSD Foundation
+    </sponsor>
+
+  </project>
+
+  <project cat='kern'>
+    <title>Randomized Top of Stack pointer</title>
+
+    <contact>
+      <person>
+	<name>Konstantin Belousov</name>
+	<email>kib@FreeBSD.org</email>
+      </person>
+    </contact>
+
+    <body>
+      <p>After the ASLR so useful addition, next in the series of
+	the
+	buzzword-compliant checkboxes is the stack addresses
+	randomization.</p>
+
+      <p>The main userspace thread stack on FreeBSD is
+	traditionally allocated
+	from the top of the user address space and grows down.
+	Besides the
+	initial pointer for the stack on userspace entry, this
+	area also
+	contains structures for program arguments and environment
+	(so called
+	strings), and aux vector data for ELF images.</p>
+
+      <p>Considering the goal of randomizing the addresses of
+	strings and main
+	thread initial frame, moving the main stack area in the
+	address space
+	is not feasible. It would cause significant ABI breakage,
+	invalidates
+	the knowledge already coded into many introspection tools,
+	and causes
+	unneeded additional fragmentation of the user address
+	space.</p>
+
+      <p>Instead a typical approach of adding a gap of randomized
+	size between
+	top of stack and a place for strings was used. It is done
+	in a way
+	which preserves the stack alignment requirement. Stack gap
+	is only
+	enabled if ASLR is enabled (not default) and stack gap
+	itself is
+	enabled (default if ASLR is enabled). Stack gap is
+	specified in
+	percentage of the total stack size that can be used for
+	maximum gap.</p>
+
+      <p>The main drawback of the gap approach was shortly
+	identified. Since
+	gap is cut from the normal stack area, attempts of the
+	programs to
+	reduce stack size using rlimit(RLIMIT_STACK) could cut the
+	active stack
+	region if new limit happens to be smaller than the gap.
+	E.g. on amd64
+	with its default 512M main thread stack, even one percent
+	of the max
+	gap gives approximately 5M of unused stack, that can blow
+	up the limit
+	of several KBs.</p>
+
+      <p>Typical reason for using rlimit(2) this way is for
+	programs that wire
+	all of its address space with mlockall(2), trying to
+	reduce potential
+	wired stack size to avoid exceeding RLIMIT_MEMLOCK.</p>
+
+      <p>First victim of that issue was ntpd, which resets the
+	stack limit
+	after start for a really small value. Currently the wiring
+	was removed
+	from ntpd, because apparently it does not make the
+	timekeeping better
+	by any means, contrary to popular belief.</p>
+
+      <p>My opinion is that the problem is more in the user
+	interface area than
+	in the gap approach itself. We should make it easy to
+	specify small
+	gap sizes, which cannot be done with integral percentage
+	interface.
+	So far I did not formulated a way to do this which I would
+	like, and
+	since nobody looked for a good solution because after ntpd
+	was fixed,
+	the severity of the issue seems very low.</p>
+
+    </body>
+
+    <sponsor>
+      The FreeBSD Foundation
+    </sponsor>
+
+  </project>
+
+  <project cat='arch'>
+    <title>Broadcom ARM64 SoC support</title>
+
+    <contact>
+      <person>
+	<name>Michal Stanek</name>
+	<email>mst@semihalf.com</email>
+      </person>
+      <person>
+	<name>Kornel Duleba</name>
+	<email>mindal@semihalf.com</email>
+      </person>
+      <person>
+	<name>Marcin Wojtas</name>
+	<email>mw@semihalf.com</email>
+      </person>
+    </contact>
+
+    <body>
+      <p>The Semihalf team continued working on FreeBSD support for
+	the
+	<a
+	href="https://www.broadcom.com/products/embedded-and-networking-processors/communications/bcm58712/">Broadcom
+	BCM5871X SoC series</a></p>
+
+      <p>BCM5871X are quad-core 64-bit ARMv8 Cortex-A57
+	communication
+	processors targeted for networking applications such as
+	10G routers,
+	gateways, control plane processing and NAS.</p>
+
+      <p>Completed since the last update:</p>
+
+      <ul>
+	<li>iProc PCIe root complex (internal and external buses):
+	fixes and improvements,</li>
+
+	<li>Crypto engine acceleration for IPsec offloading.</li>
+      </ul>
+
+      <p>
+	Todo:</p>
+
+      <ul>
+	<li>Upstreaming of work. This work is expected to be
+	submitted/merged
+	to HEAD in the Q4 of 2019.</li>
+      </ul>
+
+    </body>
+
+    <sponsor>
+      Juniper Networks, Inc
+    </sponsor>
+
+  </project>
+
+  <project cat='arch'>
+    <title>FreeBSD/powerpc Project</title>
+
+    <contact>
+      <person>
+	<name>Mark Linimon (ports)</name>
+	<email>linimon@FreeBSD.org</email>
+      </person>
+      <person>
+	<name>Justin Hibbits (src)</name>
+	<email>jhibbits@FreeBSD.org</email>
+      </person>
+      <person>
+	<name>Piotr Kubaj (ports)</name>
+	<email>pkubaj@FreeBSD.org</email>
+      </person>
+    </contact>
+
+    <links>
+      <url href="https://wiki.freebsd.org/powerpc/ports">Status of FreeBSD ports on PowerPC</url>
+      <url href="https://wiki.freebsd.org/powerpc/ports/PortsOnGcc">Status of FreeBSD ports on PowerPC built using gcc</url>
+      <url href="https://wiki.freebsd.org/powerpc/ports/PortsOnClang">Status of FreeBSD ports on PowerPC built using clang</url>
+      <url href="https://wiki.freebsd.org/powerpc/llvm-elfv2">Bringing LLVM to PowerPC64 target, using OpenPower ELF v2 ABI</url>
+    </links>
+
+    <body>
+      <p>The FreeBSD/powerpc project continues to make great
+	strides. However,
+	as we discovered at BSDCan 2019, we have not done a great
+	job of letting
+	people know.</p>
+
+      <p>Key points:</p>
+
+      <ul>
+	<li>powerpc64 src on recent hardware has been
+	production-quality for over
+	a year now.</li>
+	<li>powerpc64 ports has been developer-quality for over 18
+	months now.</li>
+      </ul>
+
+      <p>
+	The main targeted platforms:</p>
+
+      <ul>
+	<li>powerpc64 on IBM POWER8 and POWER9 chips (the most recent
+	available).
+	This is the primary focus going forward. FreeBSD 12 is
+	required;
+	FreeBSD 13 is recommended.</li>
+	<li>powerpc64 on older Apple Power Macs, on a continuing but
+	secondary
+	basis. Any FreeBSD version should work.</li>
+	<li>powerpc64 on x5000. However, this is still developer-only
+	quality.
+	FreeBSD 13 is recommended.</li>
+	<li>powerpcspe on Amiga A1222. However, this is still
+	developer-only quality.
+	FreeBSD 13 is recommended.</li>
+      </ul>
+
+      <p>
+	The software status:</p>
+
+      <ul>
+	<li>powerpc*/12 and earlier still remain on the antiquated
+	gcc4.2.1 in
+	base.</li>
+	<li>powerpc*/13 will soon be switched to llvm90 in base. A
+	great deal
+	of work has been undertaken to ensure as few regressions
+	as possible.
+	Once that switch has occurred (see llvm-elfv2 link above),
+	powerpc*/13
+	support on gcc4.2.1 will no longer be a priority.</li>
+	<li>FreeBSD.org package sets are available for powerpc64/12
+	(quarterly)
+	and powerpc64/13 (default) through the usual method.</li>
+	<li>Firefox works on powerpc64 using experimental (not-yet
+	committed) patches,</li>
+	<li>As of the most recent package build on powerpc64/13 (still
+	gcc4.2.1),
+	the following statistics apply:
+	<table class="tblbasic">
+	<tr><th> Queued </th><th> Built </th><th> Failed </th><th> Skipped </th><th> Ignored </th></tr>
+	<tr><td> 33306 </td><td> 30514 </td><td> 245 </td><td> 1686 </td><td> 861 </td></tr>
+	</table>
+	</li>
+	<li>More ports fixes are being committed every day.</li>
+      </ul>
+
+      <p>
+	Also, Piotr would like to thank the FreeBSD Foundation for
+	funding
+	his personal Talos, and Raptor (via its IntegriCloud
+	subsidiary) for
+	loaning a server on which talos.anongoth.pl runs.</p>
+
+      <p>The team would like to thank IBM for the loan of two
+	POWER8 machines,
+	and Oregon State University (OSU) for providing the
+	hosting. As well,
+	we would like to thank the clusteradm team for keeping the
+	Tyan POWER8
+	machines online that are hosted at <a
+	href="https://www.nyi.net">NYI</a>.</p>
+
+    </body>
+
+  </project>
+
+  <project cat='arch'>
+    <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>
+    </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>DPAA Network interface support</li>
+
+	<li>SD/MMC</li>
+
+	<li>USB3.0</li>
+
+	<li>I2C</li>
+
+	<li>GPIO</li>
+      </ul>
+
+      <p>
+	In progress:</p>
+
+      <ul>
+	<li>QSPI</li>
+
+	<li>Network performance improvements</li>
+      </ul>
+
+      <p>
+	Todo:</p>
+
+      <ul>
+	<li>Upstreaming of developed features. This work is expected
+	to
+	be submitted/merged to HEAD in the Q4 of 2019.</li>
+      </ul>
+
+      <p></p>
+
+    </body>
+
+    <sponsor>
+      Alstom Group
+    </sponsor>
+
+  </project>
+
+  <project cat='arch'>
+    <title>FreeBSD support for the forthcoming Arm Morello CPU, SoC, and board</title>
+
+    <contact>
+      <person>
+	<name>Robert Watson</name>
+	<email>rwatson@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>
+    </contact>
+
+    <body>
+      <p>In September 2019, Arm announced Morello, an experimental
+	multicore superscalar
+	ARMv8-A CPU, SoC, and prototype board extended to
+	implement the CHERI
+	protection model. Morello will become available in 2021.
+	More details can be
+	found in
+	<a
+	href="https://www.arm.com/blogs/blueprint/digital-security-by-design">Arm's
+	blog</a>, a
+	<a
+	href="https://www.lightbluetouchpaper.org/2019/10/18/ukri-digital-security-by-design-a-190m-research-programme-around-arms-morello-an-experimental-armv8-a-cpu-soc-and-board-with-cheri-support/">Light
+	Blue Touchpaper blog</a>,
+	and the main
+	<a
+	href="https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/">CHERI
+	website</a>.</p>
+
+      <p>We have updated CheriBSD, a CHERI-adapted version of
+	FreeBSD originally
+	targeted at the MIPS-based SRI/Cambridge CHERI processor
+	prototype, to support
+	the current draft architecture. This includes full
+	userspace spatial and
+	referential memory safety
+	
+	<a href="https://www.cl.cam.ac.uk/research/security/ctsrd/pdfs/201904-asplos-cheriabi.pdf">CheriABI</a>,
+	as well as backwards compatibility to support running
+	existing ARMv8-A
+	userspace binaries.</p>
+
+      <p>We will continue to update CheriBSD/Morello as the ISA is
+	finalised. Will also
+	closely track the public CheriBSD/MIPS trunk, picking up
+	new software features
+	utilizing CHERI as they mature, as well as to pick up
+	changes from the baseline
+	FreeBSD development trunk.</p>
+
+      <p>We currently anticipate releasing CheriBSD/Morello as open
+	source once the ISA
+	and toolchain are published in 2020.</p>
+
+      <p>Sponsors: DARPA, AFRL</p>
+
+    </body>
+
+  </project>
+
+  <project cat='ports'>
+    <title>Ports Collection</title>
+
+    <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>
+
+    <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>
+
+    <body>
+      <p>The FreeBSD Ports Management Team, tasked with overseeing
+	the Ports Tree and
+	its committers, reports that the following events happened
+	during 2019Q3:</p>
+
+      <p>The number of ports grew to just under 38,000 during the
+	last quarter. We have
+	just over 2,000 open ports PRs, of which 400 are
+	unassigned. In this period,
+	169 committers made 7,340 commits to HEAD and 561 commits
+	to the quarterly
+	branch. This shows that the trend of last quarter of
+	increased activity is
+	continuing.</p>
+
+      <p>During the last quarter, we welcomed Santhosh Raju (fox@)
+	and Dmitri Goutnik
+	(dmgk@) to the team, and said goodbye to gabor@. During
+	the last quarter,
+	feld@ decided to step down from the portmgr@ and
+	ports-secteam@ teams. We
+	would like to thank them for their past services.</p>
+
+      <p>In the last three months, bapt@ put on his engineering hat
+	and released a new
+	version of pkg (1.12), added support for overlays to the
+	Ports Tree, fixed
+	two Make targets (deinstall-depends and reinstall), and
+	cleaned up
+	bsd.sites.mk.</p>
+
+      <p>On the infrastructure side, USES=pure became obsolete and
+	has therefore been
+	removed, and two new USES, xorg and xorg-cat have been
+	added and replace the
+	old bsd.xorg.mk. Two new keywords, ldconfig and
+	ldconfig-linux, were added to
+	simplify formatting of package lists.</p>
+
+      <p>A number of default versions changed: Lazarus to 2.0.4,
+	Linux to CentOS 7,
+	LLVM to 9.0, Perl to 5.30, PostgreSQL to 11, and Ruby to
+	2.6. Of the big
+	user-visible ports, Firefox got updated to 69.0.1,
+	Firefox-esr to 68.1.0,
+	Chromium to 76.0.3809.132, and Xfce to 4.14.</p>
+
+      <p>During the last quarter, antoine@ ran 48 exp-runs to test
+	package updates, test
+	updating bsd.java.mk, test the new ldconfig and
+	ldconfig-linux keywords, test
+	default version updates, test the new xorg and xorg-cat
+	USES, test base
+	updates, and test various improvements to Go and Ruby.</p>
+
+    </body>
+
+  </project>
+
+  <project cat='ports'>
+    <title>FreshPorts</title>
+
+    <contact>
+      <person>
+	<name>Dan Langille</name>
+	<email>dvl@FreeBSD.org</email>
+      </person>
+    </contact>
+
+    <links>
+      <url href="https://www.FreshPorts.org/">FreshPorts</url>
+      <url href="https://github.com/FreshPorts/git_proc_commit">git_proc_commit code</url>
+      <url href="https://news.freshports.org/2019/09/03/things-you-didnt-know-freshports-can-do/">Things you didn’t know FreshPorts can do</url>
+    </links>
+
+    <body>
+      <p>FreshPorts consolidates commits into an easy-to-follow
+	format so you can track changes to your favorite ports.
+	It also processes src, doc, and www commit. FreshPorts
+	parses
+	incoming emails and refreshes the database with what it
+	finds.</p>
+
+      <p>In early September I started looking at how FreshPorts
+	could use a git repository for processing commits. The
+	result was <a
+	href="https://news.freshports.org/2019/09/02/git-and-freshports/">an
+	approach</a> for identifying new commits and
+	for iterating through them.</p>
+
+      <p>The next idea was <a
+	href="https://news.freshports.org/2019/09/18/moving-towards-commit-hooks/">commit
+	hooks</a> but the most interesting
+	bit of that exercise was commit iteration.</p>
+
+      <p>At the EuroBSDCon 2019 FreeBSD Developer summit, I wrote
+	up a small requirements section and then received great
+	help from two sources:</p>
+
+      <ul>
+	<li>Jan-Piet MENS recommended a <a
+	href="https://www.freshports.org/devel/py-gitpython/">Python
+	library</a> and
+	it turned out to be great</li>
+	<li>Sergey Kozlov wrote Python code to create xml using
+	that Python library</li>
+      </ul>
+
+      <p>
+	On the trip home, I was able to get the code to parse
+	a git commit into XML and loaded into a FreshPorts
+	database.</p>
+
+      <p>Returning home from the conference, I created a new
+	FreshPorts instance for processing git based on the above.
+	The website has needed no changes related to git.</p>
+
+      <p>The remaining tasks:</p>
+
+      <ul>
+	<li>automate the script (git pull, etc)</li>
+
+	<li>detect new commits (for later iteration)</li>
+
+	<li>design a light-weight git hook</li>
+      </ul>
+
+      <p>
+	Event: EuroBSDCon 2019 Hackathon
+	Sponsored by: Intel Corporation (work done by Sergey
+	Kozlov)</p>
+
+    </body>
+
+  </project>
+
+  <project cat='ports'>
+    <title>KDE on FreeBSD</title>
+
+    <contact>
+      <person>
+	<name>Adriaan de Groot</name>
+	<email>kde@FreeBSD.org</email>
+      </person>
+    </contact>
+
+    <links>
+      <url href="https://freebsd.kde.org/">KDE FreeBSD</url>
+      <url href="https://community.kde.org/FreeBSD">KDE Community FreeBSD</url>
+    </links>
+
+    <body>
+      <p>The <i>KDE on FreeBSD</i> project packages the
+	software produced by
+	the KDE Community for FreeBSD. The software includes a
+	full desktop environment, the art application
+	<a href="https://kdenlive.org">https://kdenlive.org</a>
+	and hundreds of other applications that can be used on
+	any FreeBSD desktop machine.</p>
+
+      <p>Along with KDE itself, the team maintains the Qt
+	libraries, the CMake
+	build system, and a handful of other C++ libraries used in
+	the KDE stack.</p>
+
+      <p>The upstream releases KDE Frameworks (libraries) on a
+	monthly
+	cycle, KDE Plasma (the desktop environment) quarterly and
+	a collection of KDE Applications (usable everywhere) twice
+	a year.
+	The KDE on FreeBSD team chased a dozen updates to these
+	components
+	so that FreeBSD remains one of the most up-to-date systems
+	with KDE software (and Qt).</p>
+
+      <p>A large (and possibly breaking, still needs more
+	investigation)
+	change came with the release to KDE's Digikam 6.3.0, which
+	stopped
+	using its previous plugins system (the "old" plugins are
+	still used
+	by other KDE software).</p>
+
+      <p>A new entry in the net-im category was added for Ruqola, a
+	Rocket.chat client for rich instant-messaging.</p>
+
+      <p>CMake was updated twice. This forces the rebuild of
+	several thousand
+	C++-based ports. The KDE on FreeBSD team then fixes those
+	ports,
+	regardless of whether the error is in the CMake update, or
+	in
+	the upstream code. These updates tend to take a large
+	amount of effort,
+	since they touch unfamiliar (and often very-very-legacy)
+	code.</p>
+
+      <p>The <a
+	href="https://bugs.freebsd.org/bugzilla/buglist.cgi?bug_status=New&amp;bug_status=Open&amp;bug_status=In%20Progress&amp;bug_status=UNCONFIRMED&amp;email1=kde%40FreeBSD.org&amp;emailassigned_to1=1&amp;emailtype1=substring&amp;f0=OP&amp;f1=OP&amp;f2=product&amp;f3=component&amp;f4=alias&amp;f5=short_desc&amp;f7=CP&amp;f8=CP&amp;f9=assigned_to&amp;j1=OR&amp;j_top=OR&amp;o2=substring&amp;o3=substring&amp;o4=substring&amp;o5=substring&amp;o9=substring&amp;query_format=advanced&amp;v2=kde%40&amp;v3=kde%40&amp;v4=kde%40&amp;v5=kde%40&amp;v9=kde%40&amp;human=1">open
+	bugs list</a>
+	grew to 24 this quarter.
+	It tends to hover around 20 items as new things come in
+	and old ones are resolved. We welcome detailed bug reports
+	and patches. KDE packaging updates are prepared in
+	a <a
+	href="https://github.com/freebsd/freebsd-ports-kde/">copy
+	of the ports repository</a>
+	on GitHub and then merged in SVN. We welcome pull requests
+	there as well.</p>
+
+    </body>
+
+  </project>
+
+  <project cat='ports'>
+    <title>Java on FreeBSD</title>
+
+    <contact>
+      <person>
+	<name>Greg Lewis</name>
+	<email>glewis@FreeBSD.org</email>
+      </person>
+    </contact>
+
+    <links>
+      <url href="https://github.com/freebsd/openjdk-jdk11u">OpenJDK 11 repository at FreeBSD GitHub</url>
+    </links>
+
+    <body>
+      <p>Over the last few quarters there has been considerable
+	work in improving
+	support for Java 11 and higher, with some work being
+	backported to Java 8.</p>
+
+      <p>Starting with the initial release in March on amd64, over
+	the
+	intervening months FreeBSD support was added for features
+	such as:</p>
+
+      <ul>
+	<li>Java Flight Recorder</li>
+
+	<li>HotSpot Serviceability Agent</li>
+
+	<li>HotSpot Debugger</li>
+
+	<li>DTrace</li>
+
+	<li>Javac Server</li>
+
+	<li>Java Sound</li>
+
+	<li>SCTP</li>
+      </ul>
+
+      <p>
+	In addition, support for the aarch64, i386 and powerpc64
+	architectures
+	was also added.</p>
+
+      <p>With most features supported, attention turned to
+	compliance, using the
+	internal JDK test suite as a method of measuring this.
+	Most work during
+	the third quarter has focused on this, with test failures
+	dropping from
+	50+ failures to only 2 tier1 test failures (which don't
+	appear to impact
+	functionality at all). Some significant fixes include:</p>
+
+      <ul>
+	<li>A stack overflow crash</li>
+
+	<li>Errors in external process handling</li>
+
+	<li>The unpack200 utility (on little endian systems)</li>
+
+	<li>HotSpot Debugger functionality such as thread enumeration</li>
+
+	<li>Networking functionality</li>
+      </ul>
+
+      <p>
+	Finally, this work has been forward ported to Java 12 and
+	13, with FreeBSD
+	gaining support for these versions on or just after the
+	day of release.</p>
+
+      <p>Note that this work has been a collaboration with many
+	others. While there
+	are too many contributors to list here (please take a look
+	at the commit
+	history of the GitHub repository), I'd like to recognise
+	Kurt Miller of
+	OpenBSD for his tireless work as a co-collaborator on Java
+	for BSD through
+	many years.</p>
+
+      <p>I'm also grateful to the sponsorship of the FreeBSD
+	Foundation, which has
+	allowed me to focus on this work for Q3.</p>
+
+    </body>
+
+    <sponsor>
+      FreeBSD Foundation
+    </sponsor>
+
+  </project>
+
+  <project cat='ports'>
+    <title>XFCE 4.14 update</title>
+
+    <contact>
+      <person>
+	<name>Guido Falsi</name>
+	<email>xfce@FreeBSD.org</email>
+      </person>
+    </contact>
+
+    <links>
+      <url href="https://xfce.org/about/news/?post=1565568000">XFCE 4.14 announce</url>
+    </links>
+
+    <body>
+      <p>On September 19th the XFCE desktop environment ports have
+	been updated
+	to the recently released XFCE 4.14 version.</p>
+
+      <p>These updates include upgrades of all the main XFCE
+	components to the
+	latest versions which have been migrated to GTK3, with few
+	exceptions.
+	Base components still require and link to GTK2 in addition
+	to GTK3 to
+	allow older GTK2 XFCE applications, for example panel
+	plugins, to keep
+	working.</p>
+
+      <p>Due to this change the gtk-xfce-engine theme is deprecated
+	since it only
+	supports GTK2. The XFCE metaport by default installs the
+	greybird theme,
+	but it is not enabled by default.</p>
+
+      <p>This new version also includes now it's own
+	xfce4-screensaver program
+	which is installed by default.</p>
+
+      <p>Finally the default Display Manager on which XFCE depends
+	has been
+	changed to LightDM.</p>
+
+      <p>Some regressions were reported in bugzilla. In particular
+	the one
+	affecting most users is a regression in the window
+	manager: on specific
+	graphic display hardware the window manager fails to
+	properly draw
+	window decorations, which appear black and blocky on
+	affected systems.</p>
+
+      <p>This problem has also been reported in the upstream bug
+	tracker and a
+	solution is being sought.</p>
+
+      <p>If anyone is experiencing this display glitch and is able
+	to test,
+	please contact xfce@freebsd.org to help trying to figure
+	out a solution.</p>
+
+    </body>
+
+  </project>
+
+  <project cat='third'>
+    <title>ClonOS: virtualization platform on top of FreeBSD Operating System</title>
+
+    <contact>
+      <person>
+	<name>Oleg Ginzburg</name>
+	<email>olevole@olevole.ru</email>
+      </person>
+    </contact>
+
+    <links>
+      <url href="https://clonos.tekroutine.com/download.html">ClonOS 19.09</url>
+      <url href="https://www.bsdstore.ru/">CBSD</url>
+    </links>
+
+    <body>
+      <h3>What is ClonOS?</h3>
+
+      <p>ClonOS is a turnkey open-source platform based on FreeBSD
+	and the CBSD
+	framework. ClonOS offers a complete web UI for an easy
+	control, deployment
+	and management of FreeBSD jails containers and bhyve/Xen
+	hypervisor virtual
+	environments.</p>
+
+      <p>ClonOS is currently the only available platforms which
+	allow both Xen and bhyve
+	hypervisors to coexist on the same host. Since ClonOS is a
+	FreeBSD-based
+	platform, it has the ability to create and manage jails
+	natively, allowing
+	you to run FreeBSD applications without losing
+	performance.</p>
+
+      <h3>ClonOS/CBSD 2019Q3 Status Report</h3>
+
+      <ul>
+	<li>Added support for cloud-init (Linux/BSD VMs) and
+	cloudbase-init
+	(Windows VMs). It gives the ability to use FreeBSD as IaaS
+	platform
+	for instant deployment and usage of virtual machines based
+	on bhyve
+	hypervisor.</li>
+
+	<li>Project started to use own cloud images for better
+	stability and
+      	resiliency.</li>
+
+	<li>New mirrors in France, US and Canada were added for
+      	distributing ISO/cloud-init images in addition to Russia,
+	Latvia and
+	Ukraine.</li>
+
+	<li>Now we're using Jenkins CI for testing regular ClonOS
+	builds:
+	<a
+	href="https://jenkins.ircdriven.net/job/Update%20clonos%20packages./">Update
+	clonos packages</a> (Thanks to Daniel Shafer)</li>
+
+	<li>New pkg repository was deployed to support ClonOS
+	installation
+	from packages (at this moment only FreeBSD-12 packages are
+	available)
+	<a
+	href="https://pkg.ircdriven.net/packages/12amd64-clonos/">ClonOS
+	package repo</a> (Thanks to Daniel Shafer)</li></ul>
+
+      <p>
+	Open issues and tasks:</p>
+
+      <ul>
+	<li>Volunteers, contributors and testers are urgently needed
+	to
+      	distribute ClonOS on FreeBSD environments.</li>
+
+	<li>We'd like to expand our mirrors number geographically,
+	your help and contribution will be much appriciated.</li>
+
+	<li>We're urgently looking for hosting sponsorship for various
+      developing and testing activities.</li></ul>
+
+    </body>
+
+  </project>
+
+  <project cat='third'>
+    <title>sysctlinfo</title>
+
+    <contact>
+      <person>
+	<name>Alfonso Sabato Siciliano</name>
+	<email>alfonso.siciliano@email.com</email>
+      </person>
+    </contact>
+
+    <links>
+      <url href="https://gitlab.com/alfix/sysctlinfo">gitlab.com/alfix/sysctlinfo</url>
+    </links>
+
+    <body>
+      <p>The FreeBSD kernel maintains a Management Information Base
+	(MIB) where a
+	component (object) represents a parameter of the system.
+	The <i>sysctl</i> system
+	call explores the MIB to find an object by its Object
+	Identifier (OID) and
+	calls its handler to get or set the value of the
+	parameter. It is often
+	necessary to find an object not to call its handler but to
+	get its info
+	(description, type, name, next object, etc.), so the
+	kernel provides an
+	undocumented interface implemented in kern_sysctl.c.</p>
+
+      <p>sysctlinfo is a new interface to explore the sysctl MIB
+	and to pass the info
+	of an object to the userland. The project provides: a
+	README, a manual, helper
+	macros, examples, tests and converted tools.</p>
+
+      <p>Primarily sysctlinfo provides a new set of sysctl nodes
+	(corresponding to the
+	kernel interface) to handle an object up to CTL_MAXNAME
+	levels:
+	sysctl.entryfakename, sysctl.entrydesc, sysctl.entrylabel,
+	sysctl.entrykind,
+	sysctl.entryfmt and sysctl.entrynextleaf. Moreover new
+	features have been
+	implemented: the support for the capability mode,
+	sysctl.entryname,
+	sysctl.entryidbyname and sysctl.entrynextnode. To get all
+	the info about an
+	object the kernel needs to find it many times, then the
+	new
+	sysctl.entryallinfo* nodes were written, they are 30%
+	more efficient. Finally,
+	*byname nodes were added: they search the object by its
+	name avoiding to call
+	sysctl.name2oid (or similar) to explore the MIB just to
+	find the corresponding
+	OID.</p>
+
+      <p>sysctlinfo can be installed via <i>sysutils/sysctlinfo-kmod</i>
+	or by applying the
+	<i>sysctlinfo.diff</i> patch (more efficient than the module
+	because uses a shared
+	lock). The interface is used by <i>deskutils/sysctlview
+	1.5</i>,
+	<i>sysutils/nsysctl 1.2</i> and the converted version of
+	sysctl(8), sysctlbyname(3),
+	sysctlnametomib(3), they should be used to get the value
+	of an object with 23/24
+	levels or if some level-name has only the '\0' character.
+	In the future a new
+	<i>byname</i> node will be added to allow sysctlbyname() to
+	manage a CTLTYPE_NODE with
+	a no-NULL handler, example
+	sysctlbyname("kern.proc.pid.\&lt;pid\&gt;").</p>
+
+    </body>
+
+  </project>
+
+  <project cat='third'>
+    <title>Nomad pot driver - Orchestrating jails via nomad</title>
+
+    <contact>
+      <person>
+	<name>Luca Pizzamiglio</name>
+	<email>pizzamig@FreeBSD.org</email>
+      </person>
+      <person>
+	<name>Esteban Barrios</name>
+	<email>esteban.barrios@trivago.com</email>
+      </person>
+    </contact>
+
+    <links>
+      <url href="https://github.com/trivago/nomad-pot-driver">Nomad pot driver</url>
+      <url href="https://github.com/pizzamig/pot">Pot project</url>
+    </links>
+
+    <body>
+      <p>An experimental project has started to provide jail
+	orchestration
+	based on <tt>nomad</tt> and the jail framework
+	<tt>pot</tt>, similarly to how
+	orchestration works with docker.</p>
+
+      <p>This model allows us to split the jail creation and the
+	jail deployment.
+	Jail images can be created and exported using the
+	<tt>pot</tt> framework.
+	The images can be deployed and orchestrated using
+	<tt>nomad</tt>.
+	A driver has been developed to allow <tt>nomad</tt> to
+	interact with <tt>pot</tt>.</p>
+
+      <p>One of the goals of this project is to use non-persistent
+	jails as
+	containers, allowing us to:</p>
+
+      <ul>
+	<li>define containers similar to Docker (but not identical,
+	because
+	the underlaying OS is different)</li>
+
+	<li>identify potential missing features in FreeBSD to support
+	such a computational model</li>
+      </ul>
+
+      <p>
+	In the next quarter, we will launch the first service
+	based on this
+	project.</p>
+
+      <p>Next steps are:</p>
+
+      <ul>
+	<li>provide more guides and howtos</li>
+
+	<li>improve stability, extending the tests suite</li>
+
+	<li>improving tooling to create/manage images</li>
+      </ul>
+
+      <p></p>
+
+    </body>
+
+    <sponsor>
+      trivago N.V.
+    </sponsor>
+
+  </project>
+
+  <project cat='third'>
+    <title>ENA FreeBSD Driver Update</title>
+
+    <contact>
+      <person>
+	<name>Michal Krawczyk</name>
+	<email>mk@semihalf.com</email>
+      </person>
+      <person>
+	<name>Maciej Bielski</name>
+	<email>mba@semihalf.com</email>
+      </person>
+      <person>
+	<name>Marcin Wojtas</name>
+	<email>mw@semihalf.com</email>
+      </person>
+    </contact>
+
+    <links>
+      <url href="https://github.com/amzn/amzn-drivers/blob/master/kernel/fbsd/ena/README">ENA README</url>
+    </links>
+
+    <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>ENAv2 has been under development for FreeBSD, similar to
+	Linux
+	and DPDK. Since the last update internal review and
+	improvements
+	of the patches were done, followed by validation on
+	various AWS
+	instances.</p>
+
+      <p>Completed since the last update:</p>
+
+      <ul>
+	<li>Verification and review of the NETMAP support</li>
+
+	<li>Mapping of the memory as WC on A1 instances in order to
+	enable LLQ mode</li>
+      </ul>
+
+      <p>
+	Todo:</p>
+
+      <ul>
+	<li>Upstream of NETMAP support</li>
+
+	<li>Upstream of the fix for LLQ mode on A1 instances</li>
+      </ul>
+
+      <p></p>
+
+    <sponsor>
+      Amazon.com Inc
+    </sponsor>
+
+    </body>
+
+  </project>
+
+</report>