Index: head/en_US.ISO8859-1/htdocs/news/status/report-2015-07-2015-09.xml
===================================================================
--- head/en_US.ISO8859-1/htdocs/news/status/report-2015-07-2015-09.xml	(revision 47667)
+++ head/en_US.ISO8859-1/htdocs/news/status/report-2015-07-2015-09.xml	(revision 47668)
@@ -1,3685 +1,3685 @@
 <?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$ -->
 
 <report>
   <date>
     <month>July-September</month>
 
     <year>2015</year>
   </date>
 
   <section>
     <title>Introduction</title>
 
     <p>The third quarter of 2015, from July to September, was
       again a period of busy activity for &os;: for the second quarter
       in a row we have the largest report yet published.</p>
 
     <p>The Foundation continues to play a strong role, bringing
       both a developer and evangelist presence to conferences, funding
       much of the hardware that the cluster administration team uses to
       keep things running, and sponsoring many development projects for
       &os;.  This quarter we also hear from some of the student projects
       funded by Google Summer of Code 2015, ranging a wide gamut from
       the bootloader to additional ARM support, but also at a range of
       completion status.  Some of the GSoC output is in the tree
       already, but others could benefit from additional attention to
       help out our budding new contributors as their schedules fill with
       the return to classes.</p>
 
     <p>ZFS and the network stack continue to be strong areas for
       &os;, with both receiving active maintenance and feature
       improvements during this quarter.  Substantial work continues on
       arm64, potentially putting it on the path toward a promotion to
       Tier-1 status, and a new port to the RISC-V architecture has
       made great headway in a short period of time.  But it is not just
       our strengths and exciting new areas that have seen attention this
       cycle; there are also some parts of the system that are frequently
       perceived as unchanging infrastructure that have received
       attention and improvements, with <tt>truss</tt> and
       (<tt>k</tt>)<tt>gdb</tt> receiving significant overhauls, new
       implementations for the man page tools being brought in, the
       website receiving a new skin, and a brand new system for
       translating documentation that greatly lowers the barrier to
       entry.</p>
 
     <p>Nonetheless, despite its record length, this report does
       not and cannot cover all of the work being done on &os; throughout
       the reporting period &mdash; there are many bug fixes too minor to
       mention here, and developers too busy working on the next project
       to write up an entry for the previous project.  It is not just the
       developers committing to Subversion that comprise the ongoing
       activities of &os;, but also the users testing unreleased
       code or reporting bugs in released code, and participants on the
       mailing lists and forums helping each other solve their problems.
       Even the chats on IRC that wander far from the stated topic of a
       channel contribute to the community around &os;; it is that
       community whose effectiveness and helpfulness is a key component
       of the effectiveness and usefulness of &os; itself.  Not just to
       the developers listed in this report, but to everyone in the
       community, thank you for making &os; a great operating system.</p>
 
     <p><i>&mdash;Ben Kaduk</i></p>
 
     <p><hr /></p>
 
     <p>Please submit status reports for the fourth quarter of 2015
       (from October to December) by January 7, 2016.</p>
   </section>
 
   <category>
     <name>team</name>
 
     <description>&os; Team Reports</description>
   </category>
 
   <category>
     <name>proj</name>
 
     <description>Projects</description>
   </category>
 
   <category>
     <name>kern</name>
 
     <description>Kernel</description>
   </category>
 
   <category>
     <name>arch</name>
 
     <description>Architectures</description>
   </category>
 
   <category>
     <name>bin</name>
 
     <description>Userland Programs</description>
   </category>
 
   <category>
     <name>ports</name>
 
     <description>Ports</description>
   </category>
 
   <category>
     <name>doc</name>
 
     <description>Documentation</description>
   </category>
 
   <category>
     <name>gsoc</name>
 
     <description>Google Summer of Code</description>
   </category>
 
   <category>
     <name>misc</name>
 
     <description>Miscellaneous</description>
   </category>
 
   <project cat='kern'>
     <title><tt>ioat(4)</tt> Driver Import</title>
 
     <contact>
       <person>
 	<name>
 	  <given>Jim</given>
 	  <common>Harris</common>
 	</name>
 	<email>jimharris@FreeBSD.org</email>
       </person>
 
       <person>
 	<name>
 	  <given>Conrad</given>
 	  <common>Meyer</common>
 	</name>
 	<email>cem@FreeBSD.org</email>
       </person>
     </contact>
 
     <links>
       <url href="https://en.wikipedia.org/wiki/I/O_Acceleration_Technology">Wikipedia
 	article on IOAT</url>
 
       <url href="https://svnweb.FreeBSD.org/base?view=revision&amp;revision=r287117">Commit
 	importing <tt>ioat(4)</tt></url>
     </links>
 
     <body>
       <p>A new driver, <tt>ioat(4)</tt>, was added to the tree.
 	<tt>ioat(4)</tt> supports Intel's I/O Acceleration Technology
 	devices which are found on some Intel server systems.</p>
 
       <p>These devices are DMA offload engines, which can accelerate
 	some I/O-heavy applications by offloading memory copies from
 	the main CPU to the I/OAT unit.  This acceleration is not
 	transparent; applications must be adapted to take advantage of
 	the hardware.</p>
 
       <p>Some I/OAT models support more advanced copying modes, such as 
 	XOR; these modes are not yet supported in the <tt>ioat(4)</tt>
 	driver.</p>
     </body>
 
     <sponsor>
       Intel Corporation
     </sponsor>
 
     <sponsor>
       EMC / Isilon Storage Division
     </sponsor>
 
     <help>
       <task>
 	<p>Further testing, especially on a range of device models
 	  other than BDXDE (looking for volunteers here).</p>
       </task>
 
       <task>
 	<p>Support for the more advanced copy modes.</p>
       </task>
     </help>
   </project>
 
   <project cat='kern'>
     <title>IPsec Upgrades</title>
 
     <contact>
       <person>
 	<name>
 	  <given>George</given>
 	  <common>Neville-Neil</common>
 	</name>
 	<email>gnn@FreeBSD.org</email>
       </person>
 
       <person>
 	<name>
 	  <given>John-Mark</given>
 	  <common>Gurney</common>
 	</name>
 	<email>jmg@FreeBSD.org</email>
       </person>
 
       <person>
 	<name>
 	  <given>Ermal</given>
 	  <common>Luçi</common>
 	</name>
 	<email>eri@FreeBSD.org</email>
       </person>
     </contact>
 
     <body>
       <p>IPsec is now enabled by default in the GENERIC kernel
 	configuration, and work is proceeding to speed things up in
 	various ways.  The latest changes are the addition, by
 	&a.jmg;, &a.eri;, and &a.gnn;, of AES modes both in hardware
 	and in software.  Part of this work also includes more
 	benchmarks undertaken using Conductor in the netperf project.
 	Results have been reported at BSDCan and vBSDcon with more to
 	come at EuroBSDcon and BSDCon Brasil.</p>
     </body>
 
     <sponsor>
       Netgate
     </sponsor>
 
     <sponsor>
       The FreeBSD Foundation
     </sponsor>
 
     <help>
       <task>
 	<p>Performance improvements and other tweaks are ongoing.</p>
       </task>
     </help>
   </project>
 
   <project cat='proj'>
     <title>DTrace and TCP</title>
 
     <contact>
       <person>
 	<name>
 	  <given>George</given>
 	  <common>Neville-Neil</common>
 	</name>
 	<email>gnn@FreeBSD.org</email>
       </person>
     </contact>
 
     <links>
       <url href="https://svnweb.freebsd.org/changeset/base/287759">Commit
 	adding trace points replacing TCPDEBUG</url>
     </links>
 
     <body>
       <p>With the advent of DTrace we are able to replace many of
 	the internal kernel debugging options, such as TCPDEBUG, with
 	statically defined tracepoints (SDTs).  Tracepoints have now
 	been added to the system that replicate the functionality of
 	the TCPDEBUG kernel option.  No new kernel options need to be
 	added &mdash; they are standard with any kernel that has
 	DTrace, which is included in the default GENERIC kernels in
 	10.X and HEAD.</p>
     </body>
 
     <sponsor>
       Limelight Networks
     </sponsor>
   </project>
 
   <project cat='proj'>
     <title>FreeBSD on the Acer C720 Chromebook</title>
 
     <contact>
       <person>
 	<name>
 	  <given>Michael</given>
 	  <common>Gmelin</common>
 	</name>
 	<email>freebsd@grem.de</email>
       </person>
     </contact>
 
     <links>
       <url href="http://blog.grem.de/pages/c720.html">Blog post on
 	how to get things working</url>
       <url href="http://blog.grem.de/sysadmin/FreeBSD-On-AcerC720-Merged-2015-07-25-23-30.html">Blog
 	post with links to commits in HEAD</url>
 
       <url href="http://blog.grem.de/sysadmin/FreeBSD-10.2-On-AcerC720-2015-09-19-17-00.html">Backported
 	patch for 10.2-RELEASE</url>
     </links>
 
     <body>
       <p>The Acer C720 Chromebook is an affordable (under $200) and
 	powerful little laptop that provides a battery life of up to
 	six hours running &os;.  It is a great machine for travelling
 	and coding in general.  The machine is fully functional,
 	meaning that all essential devices work: keyboard, trackpad,
 	light sensor, backlight control, display in VESA mode (fast),
 	external Display on HDMI (only VESA mirror mode), sound, USB
 	ports, SD card slot, camera, and Atheros wireless.</p>
 
       <p>This quarter, this project extended previous work on the
 	boot process and keyboard driver as well as the
 	<tt>smbus(4)</tt> driver.  It added three new drivers:
 	<tt>ig4(4)</tt> for the I2C bus, <tt>cyapa(4)</tt> for the
 	trackpad, and <tt>isl(4)</tt>, for the ambient light sensor.</p>
 
       <p>Much of the development was originally done in late 2014.
 	Since then, the patches have been massively improved and
 	merged into HEAD, so that all relevant devices work without
 	manual patching.</p>
 
       <p>For those who are unable to run HEAD, there is a
 	backported patch to 10.2-RELEASE.</p>
 
       <p>Thanks to everyone who helped in the process.  I couldn't
 	have done it without you (you know who you are).</p>
     </body>
   </project>
 
   <project cat='kern'>
     <title>Cavium LiquidIO Smart NIC Driver</title>
 
     <contact>
       <person>
 	<name>
 	  <given>Stanislaw</given>
 	  <common>Kardach</common>
 	</name>
 	<email>kda@semihalf.com</email>
       </person>
 
       <person>
 	<name>
 	  <given>Zyta</given>
 	  <common>Racia</common>
 	</name>
 	<email>zr@semihalf.com</email>
       </person>
     </contact>
 
     <links>
       <url href="http://www.cavium.com/LiquidIO_Application_Acceleration_Adapters.html">LiquidIO
 	product page</url>
     </links>
 
     <body>
       <p>This project aims to add support for the LiquidIO family
 	of high-performance programmable accelerator 10/40-gigabit
 	Ethernet network adapters.  The currently developed kernel
 	driver supports CN6640- and CN6880-based PCIe cards, enabling
 	these features:</p>
 
       <ul>
 	<li>A CNNIC API for controlling/interacting with the smart NIC
 	  from user and kernel space including:
 	  <ul>
 	    <li>Handling multiple concurrent applications running on
 	      the same device</li>
 
 	    <li>A request/reply mechanism for (a)synchronous
 	      ordered/unordered communication</li>
 
 	    <li>Remote memory operations</li>
 
 	    <li>Device shutdown/reset</li>
 	  </ul>
 	</li>
 
 	<li>A basic NIC module utilizing the CNNIC API and a
 	  Cavium-provided NIC firmware.  This module provides:
 	  <ul>
 	    <li>Single/multi-queue TX</li>
 
 	    <li>Hardware TCP/UDP checksum offloading</li>
 
 	    <li>Large Receive Offload</li>
 
 	    <li>Promiscous mode</li>
 	  </ul>
 	</li>
 
 	<li>Sysctl-based device statistics and configuration view</li>
 
 	<li>Custom firmware loading via user-built modules and
 	  &os;'s <tt>firmware(9)</tt> mechanism.</li>
       </ul>
 
       <p>The project is currently being developed in house and is
 	being prepared for upstream.  We plan on making it
 	available in &os; 11.</p>
     </body>
 
     <sponsor>
       Cavium
     </sponsor>
 
     <sponsor>
       Semihalf
     </sponsor>
 
     <help>
       <task>Upstream the code to &os; head.</task>
     </help>
   </project>
 
   <project cat='team'>
     <title>&os; Release Engineering Team</title>
 
     <contact>
       <person>
 	<name>&os;&nbsp;Release Engineering Team</name>
 	<email>re@FreeBSD.org</email>
       </person>
     </contact>
 
     <links>
       <url href="https://www.freebsd.org/releases/10.2R/announce.html">&os;&nbsp;10.2-RELEASE
 	announcement</url>
 
       <url href="http://ftp.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/">&os; development
 	  snapshots</url>
 
       <url href="https://www.freebsd.org/releases/10.3R/schedule.html">&os;&nbsp;10.3-RELEASE
 	  schedule</url>
 
       <url href="https://www.freebsd.org/releases/11.0R/schedule.html">&os;&nbsp;11.0-RELEASE
 	  schedule</url>
     </links>
 
     <body>
       <p>The &os; Release Engineering Team is responsible for setting
 	and publishing release schedules for official project releases
 	of &os;, announcing code freezes, and maintaining the
 	respective branches, among other things.</p>
 
       <p>In mid-August, the &os;&nbsp;Release Engineering Team
 	released &os;&nbsp;10.2-RELEASE, two weeks earlier than the
 	original schedule anticipated.</p>
 
       <p>The &os;&nbsp;Release Engineering Team would like to thank
 	all that have tested the BETA and RC builds and reported
 	issues during the release cycle.</p>
 
       <p>The &os;&nbsp;Release Engineering Team, with approval from
 	the &os;&nbsp;Core Team, appointed &a.marius; as the Deputy
 	Lead.</p>
     </body>
 
     <sponsor>
       The FreeBSD Foundation
     </sponsor>
   </project>
 
   <project cat='proj'>
     <title>Porting <tt>bhyve</tt> to ARM-based Platforms</title>
 
     <contact>
       <person>
 	<name>
 	  <given>Mihai</given>
 	  <common>Carabas</common>
 	</name>
 	<email>mihai@FreeBSD.org</email>
       </person>
 
       <person>
 	<name>
 	  <given>Peter</given>
 	  <common>Grehan</common>
 	</name>
 	<email>grehan@FreeBSD.org</email>
       </person>
     </contact>
 
     <links>
       <url href="https://wiki.FreeBSD.org/SummerOfCode2015/PortingBhyveToArm">Project
 	Wiki page</url>
     </links>
 
     <body>
       <p>This summer we have started porting <tt>bhyve</tt> onto ARMv7
 	platforms.  The low-level routines for ARM processors were
 	rewritten while trying to preserve the hypervisor API
 	originally created for the x86 architectures.  We managed to
 	bring up a &os; guest up to the point of initializing
 	interrupts.  There is still work to be done in order to
 	virtualize the interrupts and the timer.  Our short-term plan
 	after finishing the interrupts and the timer is porting to a
 	real hardware platform (Cubie2).</p>
     </body>
 
     <help>
       <task>
 	<p>Virtualize interrupts and timer.</p>
       </task>
 
       <task>
 	<p>Port to a real hardware platform.</p>
       </task>
 
       <task>
 	<p>Create SMP support for bhyve-on-arm.</p>
       </task>
 
       <task>
 	<p>Port to ARMv8.</p>
       </task>
     </help>
   </project>
 
   <project cat='ports'>
     <title>Bringing GitLab into the Ports Collection</title>
 
     <contact>
       <person>
 	<name>
 	  <given>Torsten</given>
 	  <common>Zühlsdorff</common>
 	</name>
 	<email>ports@toco-domains.de</email>
       </person>
 
       <person>
 	<name>
 	  <given>Michael</given>
 	  <common>Fausten</common>
 	</name>
 	<email>ports@michael-fausten.de</email>
       </person>
     </contact>
 
     <links>
       <url href="https://bugs.FreeBSD.org/bugzilla/show_bug.cgi?id=202468">PR
 	for the new port</url>
 
       <url href="https://github.com/t-zuehlsdorff/gitlabhq/blob/master/doc/install/installation-freebsd.md">Installation
 	guide</url>
 
       <url href="https://github.com/gitlabhq/gitlabhq/">GitLab
 	Source Tree</url>
     </links>
 
     <body>
       <p>GitLab is a web-based Git repository manager with many
 	features, used by more than 100.000 organizations, including
 	NASA and Alibaba.  It also is a very long-standing entry on
 	the &quot;Wanted Ports&quot; list on the &os; Wiki.</p>
 
       <p>In the last month there was steady progress, finally
 	resulting in the PR for adding the new port.  In addition to
 	the many dependencies &a.pgollucci; is working on, there was
 	already a large amount of work done.  Along with many new or
 	updated rubygems, Rails 4.1 was resurrected.  A large group of
 	committers were involved in the process and guided us through
 	the various problems and pitfalls.</p>
 
       <p>Because of the number of dependencies &mdash; we nearly hit
 	100 &mdash; making progress takes some time.  In the meantime,
 	a new major version of GitLab has already been released,
 	requiring even more dependencies and updates.  Work on this
 	version is in progress, but the first goal is to get the
 	latest stable version from the 7.14 branch into the ports
 	tree.</p>
     </body>
 
     <sponsor>
       anyMOTION GRAPHICS GmbH, Düsseldorf, Germany
     </sponsor>
 
     <help>
       <task>
 	<p>Closing all the PRs of the dependencies</p>
       </task>
 
       <task>
 	<p>Committing the GitLab port itself</p>
       </task>
 
       <task>
 	<p>Updating the port to the latest version of the 8.x
 	  branch</p>
       </task>
     </help>
   </project>
 
   <project cat='ports'>
     <title>Xfce on &os;</title>
 
     <contact>
       <person>
 	<name>&os; Xfce Team</name>
 	<email>xfce@FreeBSD.org</email>
       </person>
     </contact>
 
     <links>
       <url href="https://wiki.FreeBSD.org/Xfce">&os; Xfce
 	Project</url>
 
       <url href="https://www.assembla.com/spaces/xfce4/subversion/source">&os;
 	Xfce Repository</url>
     </links>
 
     <body>
       <p>Xfce is a free software desktop environment for Unix and
 	Unix-like platforms, such as &os;.  It aims to be fast and
 	lightweight, while still being visually appealing and easy to
 	use.</p>
 
       <p>During this quarter, the team has kept these applications
 	up-to-date:</p>
 
       <ul>
 	<li><tt>science/xfce4-equake-plugin</tt> 1.3.8</li>
 
 	<li><tt>sysutils/xfce4-power-manager</tt> 1.5.2</li>
 
 	<li><tt>x11/libexo</tt> 0.10.7</li>
 
 	<li><tt>x11/xfce4-embed-plugin</tt> 1.6.0</li>
 
 	<li><tt>x11/xfce4-verve-plugin</tt> 1.1.0</li>
 
 	<li><tt>x11/xfce4-whiskermenu-plugin</tt> 1.5.1</li>
 
 	<li><tt>x11-wm/xfce4-desktop</tt> 4.12.3</li>
 
 	<li><tt>www/midori</tt> 0.5.11</li>
       </ul>
 
       <p>We also follow the unstable releases (available in our
 	experimental repository) of:</p>
 
       <ul>
 	<li><tt>sysutils/xfce4-panel-switch</tt> 1.0.2 (utility to
 	  backup panel layouts)</li>
 
 	<li><tt>x11/xfce4-dashboard</tt> 0.5.1</li>
       </ul>
 
       <p>In the <tt>trunk</tt> branch, <tt>x11-wm/xfce4-panel</tt>
 	contains a patch to support
 	<tt>sysutils/xfce4-panel-switch</tt> (available through the
 	panel preferences).</p>
     </body>
 
     <help>
       <task>
 	<p>Test the new stable release of GLib 2.46.x with the
 	  kqueue/kevent backend enabled (it was disabled with revision
-	  <a href="https://svnweb.FreeBSD.org/ports?view=revision&amp;revision=393663">r393663</a>.
+	  <a href="https://svnweb.FreeBSD.org/ports?view=revision&amp;revision=393663">r393663</a>).
 	  Currently several features are broken, especially in Thunar,
 	  xfce4-panel, and Xfdashboard.</p>
       </task>
     </help>
   </project>
 
   <project cat='ports'>
     <title><tt>Node.js</tt> Modules</title>
 
     <contact>
       <person>
 	<name>
 	  <given>Olivier</given>
 	  <common>Duchateau</common>
 	</name>
 	<email>olivierd@FreeBSD.org</email>
       </person>
     </contact>
 
     <links>
       <url href="https://www.assembla.com/spaces/cozycloud/subversion/source">Node.js
 	modules</url>
 
       <url href="https://people.FreeBSD.org/~olivierd/porters-handbook/using-nodejs.html">Pre-draft
 	documentation</url>
     </links>
 
     <body>
       <p><tt>Node.js</tt> is a platform built on Chrome's JavaScript
 	runtime for easily building fast, scalable network
 	applications.  It uses an event-driven, non-blocking I/O model
 	that makes it lightweight and efficient, perfect for
 	data-intensive real-time applications that run across
 	distributed devices.</p>
 
       <p>The goal of this project is to make it easy to install the
 	modules available in the
 	<a href="http://npmjs.org/">npm package registry</a>.</p>
 
       <p>Currently, the repository contains more than 100 new ports,
 	in particular:</p>
 
       <ul>
 	<li>CoffeeScript (a programming language that transcompiles to
 	  JavaScript)</li>
 
 	<li>node-gyp (allows building Node.js addons, often written in
 	  C or C++)</li>
 
 	<li>Request (a simplified HTTP client)</li>
       </ul>
 
       <p>We have also written several helpers for the porting,
 	available in our experimental repository.</p>
     </body>
 
     <help>
       <task>
 	<p>Bring in <tt>grunt.js</tt> (and modules), the JavaScript
 	  task runner.</p>
       </task>
 
       <task>
-	<p>Put more effort into support of <tt>node-gyp</tt> in the
+	<p>Put more effort into support for <tt>node-gyp</tt> in the
 	  USES framework</p>
       </task>
     </help>
   </project>
 
   <project cat='proj'>
     <title>Root Remount</title>
 
     <contact>
       <person>
 	<name>
 	  <given>Edward Tomasz</given>
 	  <common>Napierala</common>
 	</name>
 	<email>trasz@FreeBSD.org</email>
       </person>
     </contact>
 
     <links>
       <url href="https://reviews.freebsd.org/D3693">Userland
 	code review</url>
     </links>
 
     <body>
       <p>A feature long missing from &os; was the ability to boot up
 	with a temporary rootfs, configure the kernel to be able to
 	access the real rootfs, and then replace the temporary root
 	with the real one.  In Linux, this functionality is known as
 	pivot_root.  The reroot project aims to provide similar
 	functionality in a different, slightly more user-friendly, way.
 	Simply put, from the user's point of view it is as simple as
 	running <tt>reboot -r</tt>.  The system performs a partial
 	shutdown, killing all processes and unmounting the rootfs, and
 	then partial bringup, mounting the new rootfs, running init,
 	and running the startup scripts as usual.</p>
 
       <p>The kernel part of the project has been committed to
 	11-CURRENT.  The userland part is at the "finishing touches"
 	stage, and is expected to be committed soon.  A merge to
 	stable/10 is planned and reroot support is planned be included
 	in &os; 10.3.</p>
     </body>
 
     <sponsor>
       The FreeBSD Foundation
     </sponsor>
   </project>
 
   <project cat='proj'>
     <title>Clang, <tt>llvm</tt>, <tt>lldb</tt>, <tt>compiler-rt</tt> and <tt>libc++</tt> Updated to 3.7.0</title>
 
     <contact>
       <person>
 	<name>
 	  <given>Dimitry</given>
 	  <common>Andric</common>
 	</name>
 	<email>dim@FreeBSD.org</email>
       </person>
 
       <person>
 	<name>
 	  <given>Ed</given>
 	  <common>Maste</common>
 	</name>
 	<email>emaste@FreeBSD.org</email>
       </person>
 
       <person>
 	<name>
 	  <given>Roman</given>
 	  <common>Divacky</common>
 	</name>
 	<email>rdivacky@FreeBSD.org</email>
       </person>
 
       <person>
 	<name>
 	  <given>Davide</given>
 	  <common>Italiano</common>
 	</name>
 	<email>davide@FreeBSD.org</email>
       </person>
     </contact>
 
     <links>
       <url href="http://llvm.org/releases/3.7.0/docs/ReleaseNotes.html">LLVM
 	3.7.0 Release Notes</url>
       <url href="http://llvm.org/releases/3.7.0/tools/clang/docs/ReleaseNotes.html">Clang 3.7.0
 	Release Notes</url>
 
       <url href="https://bugs.freebsd.org/201377">PR 201377 Ports
 	exp-run</url>
     </links>
 
     <body>
       <p>We have updated <tt>clang</tt>, <tt>llvm</tt>, <tt>lldb</tt>,
 	<tt>compiler-rt</tt>, and <tt>libc++</tt> in base to the 3.7.0
 	release.  These all contain numerous improvements.  Please see
 	the linked release notes for more detailed information.  This
 	brings us completely up-to-date with the latest upstream
 	versions of these projects.  Meanwhile, &a.emaste; is working
 	on importing the llvm.org version of <tt>libunwind</tt>.</p>
 
       <p>Like the 3.5.x and 3.6.x releases, these components require
 	C++11 support to build.  At this point, &os; 10.0 and later
 	provide that support, at least on x86. Currently, there are no
 	solid plans to MFC these versions to any stable branches, due
 	to the difficulties this would introduce for the usual upgrade
 	scenarios.</p>
 
       <p>Thanks to &a.emaste; and &a.andrew; for their help with this
 	import, and thanks to &a.antoine; for several ports
 	exp-runs.</p>
 
       <p>During the first ports exp-run, some major problems were
 	found, one introduced by a <tt>clang</tt> bug which caused
 	<tt>pow()</tt> to generate floating point exceptions in some
 	cases.  This in turn caused <tt>libpng</tt> to fail to build,
 	and one bug in <tt>libjpeg-turbo</tt>, which was caused by
 	undefined behavior.  These two problems took some time to fix,
 	after which another exp-run was done, and this resulted in
 	about a dozen newly failed ports.  For almost all of these new
 	failures, fixes were submitted and linked to the original PR
 	201377 for the exp-run.</p>
     </body>
 
     <help>
       <task>
 	Commit ports fixes for dependencies of PR 201377.
       </task>
 
       <task>
 	Test and report issues with the new tool chain.
       </task>
     </help>
   </project>
 
   <project cat='proj'>
     <title>UEFI Boot and Framebuffer Support</title>
 
     <contact>
       <person>
 	<name>
 	  <given>Ed</given>
 	  <common>Maste</common>
 	</name>
 	<email>emaste@freebsd.org</email>
       </person>
 
       <person>
 	<name>
 	  <given>Marcel</given>
 	  <common>Moolenaar</common>
 	</name>
 	<email>marcel@freebsd.org</email>
       </person>
     </contact>
 
     <body>
       <p>A number of UEFI bug fixes were committed over the last
 	quarter, improving compatibility with different UEFI
 	implementations.  This includes improvements to EFI's
 	<tt>vt(4)</tt> framebuffer driver, <tt>efifb</tt>, to handle
 	systems with high resolution displays and unusual framebuffer
 	stride values.  In particular, this improves compatibility
 	with a large number of recent Apple MacBook Pros and other
 	Macs.</p>
     </body>
 
     <help>
       <task>Test &os; head and &os;-STABLE snapshots on
 	a variety of UEFI implementations.</task>
     </help>
   </project>
 
   <project cat='proj'>
     <title>The Graphics Stack on &os;</title>
 
     <contact>
       <person>
 	<name>
 	  <common>&os; Graphics team</common>
 	</name>
 	<email>freebsd-x11@FreeBSD.org</email>
       </person>
     </contact>
 
     <links>
       <url href="https://wiki.FreeBSD.org/Graphics">Graphics
 	stack roadmap and supported hardware matrix</url>
 
       <url href="http://blogs.freebsdish.org/graphics/">Graphics
 	stack team blog</url>
 
       <url href="https://github.com/freebsd/freebsd-ports-graphics">Ports
 	development tree on GitHub</url>
     </links>
 
     <body>
       <p>The Mesa ports were updated to 10.6.8.  At the same time, the
 	ports received a major overhaul to make sure all ports are
 	correctly configured.  Dual version support was removed.
 	There is only one Mesa version for all supported &os;
 	versions.  The <tt>libosmesa</tt> port, which provided
 	the off-screen version of
 	Mesa,  was merged into the Mesa framework.</p>
 
       <p>Another big item that was included in the Mesa port is
 	OpenCL.  There are two GPU-based OpenCL implementations:
 	<tt>lang/clover</tt> for supported Radeon cards, and
 	<tt>lang/beignet</tt> for supported Intel cards (currently
 	only Ivybridge).  Thanks go to Johannes Dieterich, O.
 	Hartmann, and Koop Mast for making this happen.</p>
 
       <p>Now that Mesa is up-to-date, we can apply the same update
 	procedure to the X.Org server.  It is currently at 1.14, and
 	an update to 1.17 is ready.  It will be committed shortly.</p>
 
       <p>On the kernel side, progress has been made with the i915
 	update.  The driver is able to attach.  There are some reports
 	that the X.Org server starts but Mesa is unhappy, so
 	acceleration does not work yet.  If you want to test,
 	instructions will be posted on the wiki in the i915 update
 	article (see links).  At this stage, we can only accept
 	patches, though &mdash; we will not be able to provide
 	support.</p>
 
       <p>We attended two conferences: XDC 2015 in Toronto and
 	EuroBSDcon 2015 in Stockholm.  Reports will be posted on the
 	blog.</p>
     </body>
 
     <help>
       <task>
 	<p>See the Graphics wiki page for up-to-date information.</p>
       </task>
     </help>
   </project>
 
   <project cat='misc'>
     <title>The FreeBSD Foundation</title>
 
     <contact>
       <person>
 	<name>
 	  <given>Deb</given>
 	  <common>Goodkin</common>
 	</name>
 	<email>deb@FreeBSDFoundation.org</email>
       </person>
     </contact>
 
     <links>
       <url href="http://www.FreeBSDFoundation.org/">Foundation
 	website</url>
 
       <url href="http://freebsdjournal.com/">&os; Journal</url>
     </links>
 
     <body>
       <p>The FreeBSD Foundation is a 501(c)(3) non-profit organization
 	dedicated to supporting and promoting the &os; Project and
 	community worldwide.  Funding comes from individual and
 	corporate donations and is used to fund and manage development
 	projects, conferences and developer summits, and provide
 	travel grants to &os; developers.  The Foundation purchases
 	hardware to improve and maintain &os; infrastructure and
 	publishes &os; white papers and marketing material to promote,
 	educate, and advocate for the &os; Project.  The Foundation
 	also represents the &os; 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 &os; last
 	quarter:</p>
 
       <p>Anne Dickison and Deb Goodkin attended OSCON to promote
 	&os;.</p>
 
       <p>&a.rwatson; organized and ran the Cambridge &os; Developer
 	Summit 2015 ("BSDCam").  We provided travel grants to two &os;
 	developers to attend the summit.  Three Foundation board/staff
 	members attended too.</p>
 
       <p>&a.gnn; attended the ARM Partner Meeting where he met with 15
 	silicon and systems vendors to present the unique traits and
 	qualities of &os; and work on setting up partnerships with the
 	companies building and deploying ARM hardware.</p>
 
       <p>George and &a.rwatson; collaborated in Cambridge on
 	developing further &os;-based teaching material at
 	undergraduate and masters levels.  Part of this project was
 	funded by the Foundation.</p>
 
       <p>George planned and ran the DevSummit at vBSDCon 2015.</p>
 
       <p>We were  proud to be a sponsor of
 	<url href="http://www.verisign.com/en_US/internet-technology-news/verisign-events/vbsdcon/index.xhtml">vBSDCon
 	  2015</url>, Sept 11-13 in Washington DC.  &a.gnn; and
 	&a.emaste; presented "Supporting a BSD Project" at the
 	conference.  &a.dru;, &a.gjb;, &a.gnn;, and &a.emaste;
 	attended and represented the Foundation at both vBSDCon and
 	the &os; Developer Summit that preceded it.  We had many
 	people stop by our table to make a donation, and it was
 	another great opportunity to talk and work with people
 	face-to-face.</p>
 
       <p>Cheryl Blain and &a.jhb; promoted the Foundation and &os; at
 	the SNIA 2015 Storage Developer Conference, in Santa Clara,
 	California, Sept 21-24.  The Foundation was also a
 	sponsor.</p>
 
       <p>We sponsored Andy Turner to attend Linaro Connect in San
 	Francisco, Sept 21-25.</p>
 
       <p>&a.emaste;, our project development director, attended the
 	X.Org Developer's Conference (XDC) in Toronto, Ontario.</p>
 
       <p>We sponsored the 2015 nginx Conference and sent &os;
 	community member &a.jhb;.</p>
 
       <p>George Neville-Neil continued planning the
 	<url href="https://wiki.freebsd.org/201511VendorDevSummit">2015
 	  Silicon Valley Vendor Summit</url>, including securing
 	the venue.</p>
 
       <p>&a.bcr; and &a.erwin; helped plan and organize the EuroBSDCon
 	&os; Developer Summit.  This included setting up the working
 	groups, securing the venue, and getting the T-shirts made.</p>
 
       <p>Benedict helped organize, and he and &a.dru; participated
 	in the
 	<url href="https://wiki.freebsd.org/201507DevSummit">&os;
 	Hackathon</url> in the Linuxhotel in Essen, Germany.  It was a
 	successful weekend of fixing bugs and collaborating with
 	others.</p>
 
       <p>&a.dru; taught a &os; class in Berlin, Germany July
 	29-31.</p>
 
       <p>We were a sponsor of
 	<url href="http://womencourage.acm.org/index.cfm">womENcourage
 	  2015</url>, in Uppsala Sweden, Sept 24-26.  Dru was the
 	moderator for a panel on
 	<url href="http://womencourage.acm.org/panel2.cfm">Open Source
 	  as a Career Path</url>.  All the panelists were &os;
 	contributors including Dan Langille, Allan Jude, Benedict
 	Reuschling, and Deb Goodkin.  We also had a table at the job
 	fair and talked to a lot of students and professors about the
 	benefits of working on &os; as an alternative to an
 	internship, teaching about &os; in university classes, and
 	hosting &os; events at their schools.  Dan taught a workshop
 	on How to Contribute to an Open Source project.  Deb
 	participated in this workshop and started a discussion on
 	offering a similar workshop at BSD and non-BSD conferences.
 	The workshop would be titled "How to Contribute to &os;", and
 	participants would learn how to contribute documentation to
 	the Project.</p>
 
       <p>We continued to publish our monthly newsletters, keeping the
 	community informed on what we are doing, including event
 	recaps, testimonials, project updates, and upcoming events.
 	We received testimonials from Microsoft, NYCBus, and
 	ScaleEngine.  We also continued to approach companies to
 	provide us with testimonials to help promote their use of
 	&os;.</p>
 
       <p>Anne Dickison rebooted the Faces of &os; series and is
 	working with &os; contributors on writing their stories.
 	She continued to produce more &os; Swag and literature to
 	promote &os;, as well as advocating for &os; over our social
 	channels and with new partnerships.</p>
 
       <p>We reached our 2015 goal of 10,000 &os; Journal subscribers,
 	and we published a new Open Journal article on our website, to
 	help promote the Journal.  We also started offering a new
 	subscription bundle, where you can buy all the 2014 issues.
 	The July/August issue was published.</p>
 
       <p>&a.gibbs; began teaching a semester-long &os; class at a middle school
 	in Boulder, Colorado.  We are using the BeagleBone Black (BBB)
 	to run &os; connected to Macs and PCs.  We have received a lot
 	of support, both internally, and from the Project, to get the
 	&os; images to work on the BBB with the Macs and PCs.  It has
 	been a great collaborative effort with community members, and
 	this will help future classes in being able to support
 	inexpensive platforms for teaching &os;.</p>
 
       <p>Work continued on creating a &os; curriculum for a half day
 	workshop.  Hopefully this will be available in late
 	Spring.</p>
 
       <p>We provided legal support for the Project including granting
 	trademark permission for some users and companies who
 	requested permission to put the &os; logo on their websites
 	and marketing literature.</p>
 
       <p>We met with commercial users to get their input on what
 	they would like to see supported in &os;.  We also do this to
 	help connect &os; developers with commercial users to help
 	facilitate collaboration.</p>
 
       <p>&os; Foundation employee and Release Engineer &a.gjb; was
 	extremely busy during this quarter, working on a number of
 	exciting areas of the &os; Project.  Some of the highlights
 	include:
 
 	<ul>
 	  <li>Code cleanup and bug fixes to several parts of the
 	    release build code, and finishing adding support for
 	    automatically uploading cloud provider images, which was
 	    merged to the stable/10 branch before the code freeze.
 	    The 10.2-RELEASE cycle spanned a 9-week timeframe overall,
 	    starting from the code slush.</li>
 
 	  <li> With the &os; Release Engineering Team, released two
 	    BETA builds and three RC builds for the 10.2-RELEASE
 	    cycle, with the final release announced mid-August,
 	    two weeks ahead of the original schedule.</li>
 
 	  <li>With the &os; Cluster Administrators Team, assisted with
 	    a number of general updates and enhancements to the &os;
 	    infrastructure.</li>
 	</ul></p>
     </body>
   </project>
 
   <project cat='gsoc'>
     <title>Multiqueue Testing</title>
 
     <contact>
       <person>
 	<name>
 	  <given>Tiwei</given>
 	  <common>Bie</common>
 	</name>
 	<email>btw@FreeBSD.org</email>
       </person>
 
       <person>
 	<name>
 	  <given>Hiren</given>
 	  <common>Panchasara</common>
 	</name>
 	<email>hiren@FreeBSD.org</email>
       </person>
 
       <person>
 	<name>
 	  <given>George</given>
 	  <common>Neville-Neil</common>
 	</name>
 	<email>gnn@FreeBSD.org</email>
       </person>
 
       <person>
 	<name>
 	  <given>Robert</given>
 	  <common>Watson</common>
 	</name>
 	<email>rwatson@FreeBSD.org</email>
       </person>
     </contact>
 
     <links>
       <url href="https://wiki.FreeBSD.org/SummerOfCode2015/MultiqueueTestingProject">Project
 	Wiki Page</url>
     </links>
 
     <body>
       <p>The aim of this project is to design and implement
 	infrastructure to validate that a number of the network
 	stack's multiqueue behaviours are functioning as expected.</p>
 
       <p>At present, most of this project has been implemented.  It
 	mainly consists of two parts:</p>
 
       <ol>
 	<li>A general mechanism to collect the per-ring per-cpu
 	  statistics that can be used by all NIC drivers, and
 	  extensions to <tt>netstat(1)</tt> to report these
 	  statistics.</li>
 
 	<li>A suite of network stack behavior testing programs that
 	  consists of:
 
 	  <ul>
 	    <li>a virtual multiqueue ethernet interface
 	      (<tt>vme</tt>)</li>
 
 	    <li>a UDP packet generator based on <tt>vme</tt></li>
 
 	    <li>a UDP server based on <tt>socket(2)</tt></li>
 
 	    <li>a TCP client based on <tt>lwip</tt> and
 	      <tt>vme</tt></li>
 
 	    <li>a TCP server based on <tt>socket(2)</tt></li>
 	  </ul>
 	</li>
       </ol>
 
       <p>However, it still needs further refinements to make it
 	suitable for committing to &os; head.</p>
     </body>
 
     <sponsor>
       Google Summer of Code 2015
     </sponsor>
   </project>
 
   <project cat='ports'>
     <title>GNOME on &os;</title>
 
     <contact>
       <person>
 	<name>&os; GNOME Team</name>
 	<email>freebsd-gnome@FreeBSD.org</email>
       </person>
     </contact>
 
     <links>
       <url href="http://www.FreeBSD.org/gnome">&os; Gnome
 	website</url>
 
       <url href="https://github.com/freebsd/freebsd-ports-gnome">Devel
 	repository</url>
 
       <url href="https://wiki.gnome.org/Projects/Jhbuild/FreeBSD">Upstream
 	build bot</url>
 
       <url href="https://www.FreeBSD.org/doc/en_US.ISO8859-1/books/porters-handbook/using-gnome.html">USE_GNOME
 	Porter's Handbook chapter</url>
     </links>
 
     <body>
       <p>The &os; GNOME Team maintains the GNOME, MATE, and CINNAMON
 	desktop environments and graphical user interfaces for &os;.
 	GNOME 3 is part of the GNU Project.  MATE is a fork of the
 	GNOME 2 desktop.  CINNAMON is a desktop environment using
 	GNOME 3 technologies but with a GNOME 2 look and feel.</p>
 
       <p>This quarter, GNOME 3.16 and MATE 1.10 were committed to the
 	ports tree, followed up by some incremental improvements.  A
 	chapter covering the use of USE_GNOME within individual ports'
 	<tt>Makefile</tt>s was written and committed to the Porter's
 	Handbook.</p>
 
       <p>GNOME 3.18 has been ported.  There are, however, some issues
 	that need to be resolved before it can be committed to the
 	ports tree.</p>
     </body>
 
     <help>
       <task>
 	<p>The &os; GNOME website is stale.  Work is under way to improve
 	  it.</p>
       </task>
 
       <task>
 	<p>Please give feedback on and suggest improvements to the
 	  chapter in the Porter's Handbook on the <tt>USE_GNOME</tt>
 	  functionality.</p>
       </task>
 
       <task>
 	<p>Continue working on investigating the issues blocking
 	  GNOME 3.18.</p>
       </task>
     </help>
   </project>
 
   <project cat='arch'>
     <title>Atomics</title>
 
     <contact>
       <person>
 	<name>
 	  <given>Konstantin</given>
 	  <common>Belousov</common>
 	</name>
 	<email>kib@FreeBSD.org</email>
       </person>
 
       <person>
 	<name>
 	  <given>Alan</given>
 	  <common>Cox</common>
 	</name>
 	<email>alc@FreeBSD.org</email>
       </person>
 
       <person>
 	<name>
 	  <given>Bruce</given>
 	  <common>Evans</common>
 	</name>
 	<email>bde@FreeBSD.org</email>
       </person>
     </contact>
 
     <body>
       <p>Atomic operations serve two fundamental purposes.  First,
 	they are the building blocks for expressing synchronization
 	algorithms in a single, machine-independent way using
 	high-level languages.  In essense, atomics abstract the
 	different building blocks supported by the various
 	architectures on which &os; runs, making it easier to develop
 	and reason about lock-less code by hiding hardware-level
 	details.</p>
 
       <p>Atomics also provide the barrier operations that allow
 	software to control the effects on memory of out-of-order and
 	speculative execution in modern processors as well as
 	optimizations by compilers.  This capability is especially
 	important to multithreaded software, such as the &os; kernel,
 	when running on systems where multiple processors communicate
 	through a shared main memory.</p>
 
       <p>Each machine architecture defines a memory model, which
 	specifies the possible effects on memory of out-of-order and
 	speculative execution.  More precisely, it specifies the
 	extent to which the machine may visibly reorder memory
 	accesses to optimize performance.  Unfortunately,
 	there are almost as many models as architectures.  
 	Some architectures, for example IA32 or Sparcv9 TSO, are
 	relatively strongly ordered.  In contrast, others, like
 	PowerPC or ARM, are very relaxed.  In effect, atomics define a
 	very relaxed abstract memory model for &os;'s
 	machine-independent code that can be efficiently realized on
 	any of these architectures.</p>
 
       <p>Most &os; development and testing still happens on
 	x86 machines, which, when combined with x86's strongly ordered
 	memory model, leads to errors in the use of atomics,
 	specifically, barriers.  In other words, the code is not
 	properly written to &os;'s abstract memory model, but the
 	strong ordering of the x86 architecture hides this fact.  The
 	architectures impacted by the code that incorrectly uses
 	atomics are less popular or have limited availability, and the
 	resulting bugs from the misuse of atomics are hard to
 	diagnose.</p>
 
       <p>The goal of this project is to audit and upgrade the usage of
 	lockless facilities, hopefully fixing bugs before they are
 	observed in the wild.</p>
 
       <p>&os; defines its own set of atomics operations, like many
 	other operating systems.  But unlike other operating systems,
 	&os; models its atomics and barriers on the release
 	consistency model, which is also known as acquire/release
 	model.  This is the same model which is used by the C11 and
 	C++11 language standards as well as the new 64-bit ARM
 	architecture.  Despite having syntactical differences, C11 and
 	&os; atomics share essentially the same semantics.
 	Consequently, ample tutorials about the C11 memory model and
 	algorithms expressed with C11 atomics can be trivially reused
 	under &os;.</p>
 
       <p>One facility of C11 that was missing from &os; atomics
 	was <em>fences</em>.  Fences are bidirectional barrier
 	operations which could not be expressed by the existing
 	atomic+barrier accesses.  They were added in r285283.</p>
 
       <p>Due to the strong memory model implemented by x86 processors,
 	<tt>atomic_load_acq()</tt> and <tt>atomic_store_rel()</tt> can
 	be implemented by plain load and store instructions with only
 	a compiler barrier.  No additional ordering constraints are
 	required.  This simplification of <tt>atomic_store_rel()</tt>
 	was done some time ago in r236456.  The
 	<tt>atomic_load_acq()</tt> change was done in r285934, after
 	careful review of all its uses in the kernel and user-space to
 	ensure that no hidden dependency on a stronger implementation
 	was left.</p>
 
       <p>The only reordering in memory accesses which is allowed on
 	x86 is that loads may be reordered with older stores to
 	different locations.  This results from the use of store
 	buffers at the micro-architecural level.  So, to ensure
 	sequentially consistent behavior on x86, a store/load barrier
 	needs to be issued, which can be done with an MFENCE
 	instruction or by any locked read-modify-write operation.  The latter
 	approach is recommended by the optimization guides from Intel
 	and AMD.  It was noted that careful selection of the scratch
-	memory location, which is modified by the locked RWM
-	operation, can reduce the cost of barrier by avoiding false
+	memory location, which is modified by the locked RMW
+	operation, can reduce the cost of the barrier by avoiding false
 	data dependencies.  The corresponding optimization was
 	committed in r284901.</p>
 
       <p>The <tt>atomic(9)</tt> man page was often a cause of
 	confusion due to both erroneous and ambiguous statements.  The
 	most significant of these issues were addressed in changes
 	r286513 and r286784.</p>
 
       <p>Some examples of our preemptive fixes to the misuse of
 	atomics that would only become evident on weakly ordered
 	machines are:</p>
 
       <ul>
 	<li>A very important lockless algorithm, used in both the
 	  kernel and libc, is the timekeeping functionality
 	  implemented in <tt>kern/kern_tc.c</tt> and the userspace
 	  <tt>__vdso_gettimeofday</tt>.  This algorithm relied on x86
 	  total store order (TSO) behavior.  It was fixed in r284178
 	  and r285286.</li>
 
 	<li>The <tt>kern/kern_intr.c</tt> lockless updates to the
 	  <tt>it_need</tt> indicator were corrected in r285607.</li>
 
 	<li>An issue with
 	  <tt>kern/subr_smp.c:smp_rendezvous_cpus()</tt> not
 	  guaranteeing the visibility of updates done on other CPUs to
 	  the caller was fixed in r285771.</li>
 
 	<li>The <tt>pthread_once()</tt> implementation was fixed to
 	  include missed barriers in r287556.</li>
       </ul>
     </body>
 
     <sponsor>
       The FreeBSD Foundation (Konstantin Belousov's work)
     </sponsor>
   </project>
 
   <project cat='arch'>
     <title>FreeBSD/RISC-V Port</title>
 
     <contact>
       <person>
 	<name>
 	  <given>Ruslan</given>
 	  <common>Bukin</common>
 	</name>
 	<email>br@FreeBSD.org</email>
       </person>
 
       <person>
 	<name>
 	  <given>Arun</given>
 	  <common>Thomas</common>
 	</name>
 	<email>arun.thomas@baesystems.com</email>
       </person>
 
       <person>
 	<name>
 	  <given>Ed</given>
 	  <common>Maste</common>
 	</name>
 	<email>emaste@FreeBSD.org</email>
       </person>
     </contact>
 
     <links>
       <url href="https://wiki.freebsd.org/riscv">&os;
 	wiki RISC-V</url>
 
       <url href="https://people.freebsd.org/~br/riscv-singleuser.txt">Single
 	user boot log</url>
     </links>
 
     <body>
       <p>RISC-V is an open source Instruction Set Architecture (ISA)
 	designed at UC Berkeley.  It is freely available for all uses
 	without requiring fees or license agreements.
 	The RISC-V team intends to provide freely available
 	BSD licensed CPU designs.</p>
 
       <p>&a.br; (University of Cambridge) now has &os; booting
 	to a single user shell on a RISC-V simulator.
 	The porting effort started only two months ago
 	and is very much a work in progress, requiring significant
 	refactoring and clean up before it reaches a committable
 	state.  Nonetheless, this is exceptional progress in a short
 	time.  The porting effort also identified a number of
 	proposed ISA improvements.</p>
 
       <p>The port currently uses the GNU tool chain (GCC and
 	binutils), and runs on the Spike simulator.  Improved RISC-V
 	support in Clang/LLVM and related tools is highly desired.</p>
     </body>
 
     <sponsor>
       DARPA, AFRL
     </sponsor>
   </project>
 
   <project cat='ports'>
     <title>Ports on PowerPC</title>
 
     <contact>
       <person>
 	<name>
 	  <given>Alexey</given>
 	  <common>Dokuchaev</common>
 	</name>
 	<email>danfe@FreeBSD.org</email>
       </person>
     </contact>
 
     <body>
       <p>The Ports Collection typically receives less attention on
 	Tier-2 architectures than on Tier-1 architectures, although
 	several build-runs were performed at various points in the
 	past, and broken ports were marked as such at those times.</p>
 
       <p>Some of the Tier-2 platforms, such as PowerPC and ARM,
 	have improved considerably recently, both on &os;'s and the
 	compilers' sides, but as the tree is not rebuilt on the
 	cluster very often, it was suspected that many ports are
 	marked BROKEN while they in fact now build and run
 	correctly.</p>
 
       <p>Over the past several weeks, 26 ports that were indeed
 	broken on at least PowerPC had been fixed, 58 ports that were
 	incorrectly marked as broken (leftovers from the old times)
 	were marked as working, and fewer than 40 ports still have
 	issues requiring further work.</p>
     </body>
 
     <help>
       <task>
 	<p>The Ports Collection could benefit a lot from more frequent
 	  sweeps targeting Tier-2 systems.</p>
       </task>
 
       <task>
 	<p>Recent work on QEMU-backed emulators and the
 	  much-anticipated cross-building of ports are essential
 	  pieces to bring &os; packages on par with the base system's
 	  support, architecture-wise.</p>
       </task>
     </help>
   </project>
 
   <project cat='team'>
     <title>The &os; Core Team</title>
 
     <contact>
       <person>
 	<name>&os; Core Team</name>
 	<email>core@FreeBSD.org</email>
       </person>
     </contact>
 
     <body>
       <p>The biggest task handled by the Core Team during this quarter
 	was developing and publishing the new Code of Conduct.  The
 	Code of Conduct describes how people are expected to behave on
 	all &os; official communication channels, as well as how
 	developers and other people involved with the project are to
 	behave when representing the project in public.</p>
 
       <p>The Code of Conduct was generally well received and elicited
 	numerous comments and suggestions for improvements from the
 	community, many of which have been integrated.</p>
 
       <p>The next task handled by Core was the restoration of Babak
 	Farrokhi's ports commit bit.  Babak resides in Iran.  A few
 	years ago, legal advice suggested that allowing contributions
 	from Iranian residents might violate US trade sanctions.
 	After several years, Core was asked to revisit the issue.  On
 	the advice of counsel, Core decided that it could restore
 	commit privileges to commmitters residing in Iran.</p>
 
       <p>The CTM service came under security review.  Given that the
 	lack of use of routine authenticity checking made the
 	injection of trivial exploit code relatively easy, the service
 	was held to be too risky to continue as an official part of
 	the &os; base system.  CTM has very few remaining users but
 	they should be able to install CTM from the Ports Collection
 	in order to continue doing so.</p>
 
       <p>Core learned that ISC was ceasing its hosting service, which
 	has entailed a rapid rework of plans on the movement of
 	significant portions of the &os; cluster to that data center.
 	Cluster administration has taken ownership of the situation
 	and is making progress.</p>
 
       <p>Core fielded an enquiry about NextBSD and whether this should
 	be the future direction for the whole &os; project.  Core's
 	position is that NextBSD is an interesting project, and we
 	regard it, like the other BSD projects, as a potential source
 	of good ideas.  However, we currently have no plans to adopt
 	NextBSD as the official &os; distribution.</p>
 
       <p>Beyond these issues, Core also spent time in various routine
 	activities.  During this quarter we issued three new src
 	commit bits, and took none in for safekeeping.  Welcome to
 	&a.allanjude;, &a.araujo;, and &a.avos;.</p>
     </body>
   </project>
 
   <project cat='ports'>
     <title>Ports Collection</title>
 
     <contact>
       <person>
 	<name>
 	  <given>Frederic</given>
 	  <common>Culot</common>
 	</name>
 	<email>portmgr-secretary@FreeBSD.org</email>
       </person>
 
       <person>
 	<name>&os; Ports Management Team</name>
 	<email>portmgr@FreeBSD.org</email>
       </person>
     </contact>
 
     <links>
       <url href="http://www.FreeBSD.org/ports/">Ports Collection
 	website</url>
 
       <url href="https://www.freebsd.org/doc/en/articles/contributing/ports-contributing.html">Contributing
 	to the Ports Collection</url>
 
       <url href="http://portsmon.FreeBSD.org/index.html">Port
 	Monitoring service</url>
 
       <url href="http://www.FreeBSD.org/portmgr/index.html">Team
 	Website</url>
 
       <url href="http://blogs.freebsdish.org/portmgr/">Blog</url>
 
       <url href="http://www.twitter.com/freebsd_portmgr/">Twitter
 	feed</url>
 
       <url href="http://www.facebook.com/portmgr">Facebook page</url>
 
       <url href="http://plus.google.com/communities/108335846196454338383">Google+
 	page</url>
     </links>
 
     <body>
       <p>As of the end of Q3 the ports tree holds just over
 	25,000 ports, and the PR count is above 2,000.  The summer
 	period saw less activity on the ports tree than during the
 	previous quarter, with fewer than 7,000 commits performed by
 	120 active committers.  Unfortunately, the number of problem
 	reports closed also decreased significantly, with fewer than
 	1,500 problem reports fixed during Q3.</p>
 
       <p>In Q3 several commit bits were taken in for safekeeping,
 	following an inactivity period of more than 18 months
 	(fluffy), or on committer's request (xmj, stefan, brix).  One
 	new developer was granted a ports commit bit
 	(&a.junovitch.email;), and one returning committer
 	(&a.farrokhi;) had his commit bit reinstated.</p>
 
       <p>On the management side, no changes were made to the
 	portmgr team during Q3.</p>
 
       <p>On the QA side, 25 exp-runs were performed to validate
 	sensitive updates or cleanups.  Amongst those, the noticeable
 	changes are the update to <tt>pkg</tt> 1.6, the
 	<tt>automake14</tt> removal, and several important port
 	updates such as <tt>doxygen</tt> to 1.8.10, <tt>gnome3</tt> to
 	3.16, <tt>cmake</tt> to 3.3.1, and the Qt4 ports to 4.8.7.
 	The default jdk was also set to <tt>openjdk8</tt>.  Some
 	infrastructure changes included the addition of new options
 	helpers: <tt>opt_VARS</tt>, <tt>opt_VARS_OFF</tt>,
 	<tt>opt_IMPLIES</tt>, and <tt>opt_PREVENTS</tt>.  Some macros
 	were also removed, such as <tt>UNIQUENAME</tt> and
 	<tt>LATEST_LINK</tt>.</p>
     </body>
 
     <help>
       <task>
 	<p>We would like to remind everyone that the ports tree is
 	  built and run by volunteers, and any help is greatly
 	  appreciated.  This is more important than ever, since the
 	  number of problem reports cannot seem to stop increasing.
 	  So if you use ports or packages, please consider jumping in
 	  and helping! This is also true for existing porters: it
 	  would be great if you would consider the next step, which is
 	  to share your knowledge and mentor someone more junior with
 	  the ports tree internals.  And if you already do these
 	  tasks, many thanks to you! </p>
       </task>
     </help>
   </project>
 
   <project cat='team'>
     <title>&os; Cluster Administration Team</title>
 
     <contact>
       <person>
 	<name>&os; Cluster Administration Team</name>
 	<!-- email intentionally left incomplete -->
 	<email>clusteradm@</email>
       </person>
     </contact>
 
     <body>
       <p>The &os; 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.</p>
 
       <p>Our primary cluster has been hosted as a guest in California
 	for many years.  Our ongoing project is relocating the core
 	functionality to a location in New Jersey with a formal
 	hosting arrangement.  This is an equipment refresh,
 	consolidation for better use of resources, and for better
 	continuity of service.</p>
 
       <p>There is a significant amount of behind-the-scenes work to
 	make this happen.  The original cluster was implemented with
 	a common, shared, assumed-to-be secure network with
 	ubiquitous NFS everywhere.  This structure does not lend
 	itself well to being distributed across geographically
 	diverse locations, particularly when Internet transit is
 	required.  The bulk of the work is rebuilding services to be
 	portable, stand-alone components that do not depend on
 	shared-network access and are safe enough to use across the
 	insecure Internet.</p>
 
       <p>Highlights this quarter:</p>
 
       <ul>
 	<li>Many internal distribution systems switched from rsync to
 	  a distribution mesh using &quot;syncthing&quot;.</li>
 
 	<li>We have implemented more code/data signing infrastructure
 	  with out-of-band verification.</li>
 
 	<li>New 32-core reference build hosts are online.</li>
 
 	<li>Internal admbugs switched from bugzilla 4.4 to 5.0 and
 	  packages were made available for the bugmeister team.</li>
 
 	<li>Finally switched from varnish3 to varnish4.</li>
 
 	<li>We exorcised hub.FreeBSD.org, the last survivor of the
 	  2012 security incident.</li>
 
 	<li>vuxml and the legacy portaudit build system were converted
 	  to components and integrated.</li>
 
 	<li>https://download.FreeBSD.org/ is nearing completion
 	  (please do not use until officially announced).</li>
 
 	<li>A Taiwan node was brought into service for pkg, ftp,
 	  svn, and vuxml mirroring.</li>
 
 	<li>One of the freebsd-update mirrors was converted from
 	  lighttpd to nginx due to a data corruption bug.</li>
 
 	<li>We completed detachment of the svn repository from the old
 	  cluster and moved it to its new location.</li>
       </ul>
 
       <p>Ongoing:</p>
 
       <ul>
 	<li>The cluster runs a mixture of 11-current and 10-stable as
 	  part of our &quot;eat our own dogfood&quot; project.  For
 	  this to be useful, we do monthly cluster refreshes to keep
 	  up with current code.</li>
 
 	<li>We build internal base system snapshots every few days
 	  and packages every day.</li>
 
 	<li>We also provide support for non-clusteradm-operated
 	  services including jenkins, reviews, portsnap,
 	  freebsd-update, bugzilla, package builders, git, and
 	  mercurial.  This varies from as little as maintaining SSL
 	  front-ends through operating servers, distributing data or
 	  building packages/binaries to run.</li>
       </ul>
     </body>
   </project>
 
   <project cat='ports'>
     <title>KDE on &os;</title>
 
     <contact>
       <person>
 	<name>KDE on &os; team</name>
 	<email>kde@FreeBSD.org</email>
       </person>
     </contact>
 
     <links>
       <url href="https://freebsd.kde.org/">KDE on &os; website</url>
 
       <url href="https://freebsd.kde.org/area51.php">KDE ports staging
 	area</url>
 
       <url href="https://wiki.FreeBSD.org/KDE">KDE on &os; wiki</url>
 
       <url href="https://mail.kde.org/mailman/listinfo/kde-freebsd">KDE/&os;
 	mailing list</url>
 
       <url href="http://src.mouf.net/area51/log/branches/plasma5">Development
 	repository for integrating KDE 5</url>
     </links>
 
     <body>
       <p>Overall, we have updated the following ports this
 	quarter:</p>
 
       <ul>
 	<li>CMake 3.3.1 (r396266)</li>
 
 	<li>Qt 4.8.7 (r397043)</li>
 
 	<li>QtCreator 3.5.0 (r395935)</li>
 
 	<li>Fixed some dependencies, typos and plists in Qt5-ports
 	  (r396044-r396047), spotted by Ralf Nolden</li>
       </ul>
 
       <p>In our development repository, we have done the following
 	work:</p>
 
       <ul>
 	<li>Updated PyQt-bindings for qt4 to 4.11.4 and added qt5
 	  bindings 5.5, contributed by Guido Falsi, and modified by
 	  Tobias Berner (area51)</li>
 
 	<li>Updated qt5 to 5.5.0.  Ralf Nolden has contributed a
 	  handful of useful new ports, for example
 	  <tt>lang/qt5-l10n</tt> (<tt>area51/qt-5.5</tt>)</li>
 
 	<li>The <tt>plasma5</tt> branch has been kept up to date with
 	  KDE's upstream and contains ports for Frameworks 5.14.0,
 	  Plasma Desktop 5.4.2 and Applications 15.08.1
 	  (<tt>area51/plasma5</tt>)</li>
       </ul>
     </body>
 
     <help>
       <task>
 	<p>Work on getting the stuff from <tt>plasma5</tt> branch into
 	  ports.  (This is a major update to nearly all KDE
 	  applications, so testers are very welcome.)</p>
       </task>
 
       <task>
 	<p>Finalize the work on PyQt5.</p>
       </task>
 
       <task>
 	<p>Port <tt>qt5-webengine</tt>.  Qt-5.5 will probably be the
 	  last release shipping a <tt>www/webkit-qt5</tt> port.</p>
       </task>
     </help>
   </project>
 
   <project cat="arch">
     <title>&os;/arm64</title>
 
     <contact>
       <person>
 	<name>
 	  <given>Andrew</given>
 	  <common>Turner</common>
 	</name>
 	<email>andrew@FreeBSD.org</email>
       </person>
 
       <person>
 	<name>
 	  <given>Ed</given>
 	  <common>Maste</common>
 	</name>
 	<email>emaste@FreeBSD.org</email>
       </person>
     </contact>
     <!-- Optional section but highly encouraged. -->
     <links>
       <url href="https://wiki.FreeBSD.org/arm64" >&os; arm64 wiki
 	page</url>
     </links>
 
     <body>
       <p>Numerous cleanups and fixes have been applied to the arm64
 	kernel.  This includes fixes to exception handling,
 	asynchronous signals, ddb, and pmap.  ddb has been updated to
 	better handle accessing memory that may be unmapped.  The pmap
 	code was made more complete by implementing more functions as
 	needed.</p>
 
       <p>Further work on SMP means that &os; now boots on all 48
 	cores on the Cavium ThunderX platform.  This includes adding
 	support for the ARM GICv3 interrupt controllers and fixing the
 	memory mapping to be shareable between CPUs.</p>
 
       <p>The test suite has been run on both qemu and hardware.  Most
 	of the test cases are passing, with around 30 tests either
 	broken or failing.  Work on diagnosing the issues with the
 	remaining test cases is ongoing.
       </p>
     </body>
 
     <sponsor>
       The FreeBSD Foundation
     </sponsor>
 
     <sponsor>
       ABT Systems Ltd
     </sponsor>
 
     <help>
       <task>
 	<p>Port to more SoCs.</p>
       </task>
     </help>
   </project>
 
   <project cat="arch">
     <title>&os; on the HiKey ARMv8 Board</title>
 
     <contact>
       <person>
 	<name>
 	  <given>Andrew</given>
 	  <common>Turner</common>
 	</name>
 	<email>andrew@FreeBSD.org</email>
       </person>
     </contact>
 
     <links>
       <url href="https://wiki.FreeBSD.org/arm64/HiKey">HiKey wiki
 	entry</url>
 
       <url href="https://www.96boards.org/products/ce/hikey/">Hardware
 	description</url>
     </links>
 
     <body>
       <p>The HiKey is a low-cost ARMv8 development board from the
 	Linaro 96boards initiative.  It contains a HiSilicon Kirin
 	6220 with eight ARMv8 cores and 1GB of ram.</p>
 
       <p>&os; has been ported to run on the HiKey with a minimal set
 	of drivers.  As of this report, &os; supports the micro-SD
 	slot and USB host, and will boot off the SD card to multi-user
 	mode using a recent arm64 snapshot.</p>
 
       <p>The kernel is missing a number of device drivers.  However,
 	it is at a usable state for people interested in testing &os;
 	on ARMv8 hardware.</p>
     </body>
 
     <sponsor>
       ABT Systems Ltd
     </sponsor>
 
     <sponsor>
       ARM Ltd
     </sponsor>
 
     <help>
       <task>
 	<p>A driver for SDIO and the onboard WiFi.</p>
       </task>
 
       <task>
 	<p>Fix the MMC driver to access the eMMC.</p>
       </task>
 
       <task>
 	<p>Support the USB in OTG mode.</p>
       </task>
 
       <task>
 	<p>Support a display via HDMI.</p>
       </task>
 
       <task>
 	<p>Add thermal management.</p>
       </task>
     </help>
   </project>
 
   <project cat='doc'>
     <title>PO Translation Project</title>
 
     <contact>
       <person>
 	<name>&os; Documentation Team</name>
 	<email>freebsd-doc@FreeBSD.org</email>
       </person>
 
       <person>
 	<name>&os; Translators</name>
 	<email>freebsd-translators@FreeBSD.org</email>
       </person>
 
       <person>
 	<name>
 	  <given>Warren</given>
 	  <common>Block</common>
 	</name>
 	<email>wblock@FreeBSD.org</email>
       </person>
     </contact>
 
     <links>
       <url href="https://www.FreeBSD.org/doc/en_US.ISO8859-1/books/fdp-primer/po-translations.html">PO
 	Translations</url>
       <url href="https://www.FreeBSD.org/doc/de_DE.ISO8859-1/articles/leap-seconds/">German
 	translation of the Leap Seconds article</url>
       <url href="https://www.FreeBSD.org/doc/nl_NL.ISO8859-1/articles/explaining-bsd/">Dutch
 	translation of the Explaining BSD article</url>
       <url href="https://lists.FreeBSD.org/pipermail/freebsd-translators/">&os;
 	Translators mailing list</url>
     </links>
 
     <body>
       <p>The &os; documentation translation process has been in need
 	of modernization for quite some time.  The existing process
 	was just too difficult for translators to keep translations up
 	to date.</p>
 
       <p>With help from Benedict Reuschling, Shaun McCance, Ryan
 	Lortie, Hiroki Sato, and many others, the availability of a
 	new PO translation system was announced in August.</p>
 
       <p>PO translations handle most of the overhead of the
 	translation process.  Translators do not have to keep track of
 	commits to the upstream English version.  The actual work of
 	translating is quicker and easier.  PO editors show how much
 	of the document has been translated.  If a translation is
 	already available for a given string, it can be easily
 	reused.</p>
 
       <p>Early testing has been very successful.  Most issues involve
 	discovering and documenting the new processes rather than
 	fixing bugs.  New translations of English documents have
 	already been committed.</p>
 
       <p>There will certainly be additional changes and improvements,
 	but the system works.  We will continue to discover how to
 	share work between translation teams and the project as a
 	whole.  This work will be much easier now that the initial
 	hurdle of being able to use PO software has been passed.
       </p>
     </body>
 
     <help>
       <task>
 	<p>Continue testing.  The system is new to us and there are
 	  bound to be bugs and situations with unexpected results.</p>
       </task>
 
       <task>
 	<p>Improve documentation on using the new PO translations.
 	  Much of this involves things that rarely happened with
 	  the old system, like adding a completely new language
 	  directory.</p>
       </task>
 
       <task>
 	<p>Add new translations for existing documents.  There is much
 	  less work to create and update a translated document
 	  now.  Existing and new translators are working on adding and
 	  updating translations of the English documentation.</p>
       </task>
 
       <task>
 	<p>Figure out how to generate and share translation memory
 	  with other members of a language team or translators outside
 	  the team.</p>
       </task>
 
       <task>
 	<p>Test new PO editors like Pootle and Virtaal.</p>
       </task>
 
       <task>
 	<p>Determine a method to allow translators commit access for
 	  translations.</p>
       </task>
 
       <task>
 	<p>Develop and test code to translate manual pages.</p>
       </task>
     </help>
   </project>
 
   <project cat='doc'>
     <title>Website CSS Update</title>
 
     <contact>
       <person>
 	<name>
 	  <given>Warren</given>
 	  <common>Block</common>
 	</name>
 	<email>wblock@FreeBSD.org</email>
       </person>
     </contact>
 
     <links>
       <url href="https://www.FreeBSD.org/">&os; Main Site</url>
     </links>
 
     <body>
       <p>The &os; website has remained essentially unchanged in
 	appearance for many years.  Like other legacy systems, it is
 	difficult to change.  It is heavily used and therefore subject
 	to non-trivial bikeshedding.</p>
 
       <p>The CSS shrunk the reader's font from the size they had
 	requested.  It specified hardcoded font and object sizes in
 	pixels.  On wide monitors, only the middle third of the screen
 	was used.  Hardware has changed from what existed when
 	this version of the site was created.  Screens have become
 	larger and wider, and increased in resolution at the same
 	time.</p>
 
       <p>It was time for a change.  Font sizes were set to
 	percentages, with none smaller than 100%.  The width of the
 	main box was changed to 90%.  Other small adjustments were
 	added.  These limited changes produced a rendered site that
 	better respects the reader's settings, is much easier to read,
 	and shows more information.</p>
 
       <p>Although no content changed, the appearance was so different
 	that some viewers thought we had redesigned the site.  It is
 	gratifying to know that so many people are using it.  We would
 	also like to thank people for the response, which was
 	overwhelmingly positive and hardly bikesheddy at all.</p>
     </body>
 
     <help>
       <task>
 	<p>Fix other outdated assumptions in the CSS.  Alternately,
 	  rework the entire site.  However, that is a much more
 	  complex and ambitious project than it might seem.</p>
       </task>
     </help>
   </project>
 
   <project cat='bin'>
     <title><tt>pkg</tt> 1.6</title>
 
     <contact>
       <person>
 	<name>&os; <tt>pkg</tt> Team</name>
 	<email>pkg@FreeBSD.org</email>
       </person>
     </contact>
 
     <body>
       <p><tt>pkg</tt> 1.6.0 has been released.  Many changes have been
 	made since <tt>pkg</tt> 1.5:</p>
 
       <ul>
 	<li>The dependency solver is greatly improved</li>
 
 	<li>Lots of fixes in the three-way merge code</li>
 
 	<li><tt>pkg add</tt> can now work without a version specified
 	  in the dependency line</li>
 
 	<li><tt>pkg check -d</tt> now also checks the required
 	  libraries</li>
 
 	<li>Improved support for partial upgrades</li>
 
 	<li>Improved <tt>zsh</tt> completion support</li>
 
 	<li>Improved Linux support: all regression tests now pass on
 	  Linux</li>
 
 	<li>Messages can now be context-aware, showing a given
 	  message always, or only during installation, upgrade
 	  (conditional on the previous version), or removal</li>
 
 	<li><tt>@keywords</tt> now accept new entries to add context-aware
 	  messages</li>
 
 	<li>Added the ability to generate graphiz's dot format
 	  representation of the solver's problem</li>
 
 	<li><tt>pkg search</tt> now defaults to showing the
 	  <tt>pkg-comments</tt> of the matched packages</li>
 
 	<li>Lots of bug fixes and code cleanup</li>
 
 	<li>Improvements in cross-installation support</li>
       </ul>
     </body>
 
     <help>
       <task>
 	<p>Add a notion of priority to the list of files to ensure
 	  that certain files are the first to be replaced.  This was a
 	  blocker for packaging base.</p>
       </task>
 
       <task>
 	<p>Investigate replacing <tt>openssl</tt> by
 	  <tt>mbedtls</tt>.</p>
       </task>
     </help>
   </project>
 
   <project cat='kern'>
     <title>&os; Xen</title>
 
     <contact>
       <person>
 	<name>
 	  <given>Roger</given>
 	  <common>Pau Monné</common>
 	</name>
 	<email>royger@FreeBSD.org</email>
       </person>
 
       <person>
 	<name>
 	  <given>Julien</given>
 	  <common>Grall</common>
 	</name>
 	<email>julien.grall@citrix.com</email>
       </person>
     </contact>
 
     <links>
       <url href="http://wiki.xen.org/wiki/FreeBSD_PVH">&os; PVH DomU
 	wiki page</url>
 
       <url href="http://wiki.xen.org/wiki/FreeBSD_Dom0">&os; PVH Dom0
 	wiki page</url>
 
       <url href="http://www.xenproject.org/component/allvideoshare/video/latest/bsdcan-2015-how-to-port-bsd-as-a-xen-on-arm-guest.html">Porting
 	&os; as a Xen ARM guest</url>
     </links>
 
     <body>
       <p>Xen is a hypervisor using a microkernel design, providing
 	services that allow multiple computer operating systems to
 	execute on the same computer hardware concurrently.  Xen
 	support for &os; on x86 as a guest was introduced in version 8
 	and ARM support is currently being worked on.  Support for
 	running &os; as an amd64 Xen host (Dom0) is available in
 	HEAD.</p>
 
       <p>On the x86 front, most of the work during this quarter
 	focused on the implementation of PVH inside Xen.
 	Consequently, most of the activity happened inside of the
 	hypervisor.  Patches for a clean PVH implementation have been
 	posted, with the aim of having them merged in the next Xen
 	release (4.7).  Once that is done, work will continue
 	adding new features to both &os; and Xen to have feature
 	parity with traditional PV guests/hosts.</p>
 
       <p>Apart from this, work is ongoing to import a new netfront
 	from Linux in order to support new features, like split event
 	channel and multiple queue support.</p>
 
       <p>On the ARM front, this quarter's work focused on getting
 	&os;/arm64 booting as a Xen guest.  The current activity is to
 	upstream patches preparing Xen drivers to support arm64.  This
 	includes a rework of the console driver.</p>
     </body>
 
     <sponsor>
       Citrix Systems R&amp;D
       </sponsor>
 
     <help>
       <task>
 	<p>Generalize the event channel code so it can be used on
 	  ARM.</p>
       </task>
 
       <task>
 	<p>Improve backend (netback, blkback) performance.</p>
       </task>
 
       <task>
 	<p>Work with upstream Xen to improve PVH and make it
 	  stable.</p>
       </task>
 
       <task>
 	<p>Improve the generic bounce buffer code for unmapped bios in
 	  order to support the alignment requirements of the
 	  blkfront driver.</p>
       </task>
     </help>
   </project>
 
   <project cat='proj'>
     <title><tt>bhyve</tt></title>
 
     <contact>
       <person>
 	<name>
 	  <given>Peter</given>
 	  <common>Grehan</common>
 	</name>
 	<email>grehan@FreeBSD.org</email>
       </person>
 
       <person>
 	<name>
 	  <given>Neel</given>
 	  <common>Natu</common>
 	</name>
 	<email>neel@FreeBSD.org</email>
       </person>
 
       <person>
 	<name>
 	  <given>Tycho</given>
 	  <common>Nightingale</common>
 	</name>
 	<email>tychon@FreeBSD.org</email>
       </person>
 
       <person>
 	<name>
 	  <given>Allan</given>
 	  <common>Jude</common>
 	</name>
 	<email>freebsd@allanjude.com</email>
       </person>
 
       <person>
 	<name>
 	  <given>Michael</given>
 	  <common>Dexter</common>
 	</name>
 	<email>editor@callfortesting.org</email>
       </person>
     </contact>
 
     <links>
       <url href="http://www.bhyve.org">bhyve FAQ and talks</url>
       <url href="https://wiki.FreeBSD.org/SummerOfCode2015/NE2000EmulationForBhyve">NE2000
 	device emulation GSoC project</url>
 
       <url href="https://wiki.FreeBSD.org/SummerOfCode2015/PortingBhyveToArm">Porting
 	bhyve to ARM GSoC project</url>
 
       <url href="https://wiki.FreeBSD.org/SummerOfCode2015/ptnetmapOnBhyve">ptnetmap
 	support in bhyve GSoC project</url>
       <url href="http://docs.FreeBSD.org/cgi/mid.cgi?561187FB.8040506">Windows
 	support</url> 
 
       <url href="http://docs.FreeBSD.org/cgi/mid.cgi?56118B2B.2040101">Illumos
 	support</url>
     </links>
 
     <body>
       <p><tt>bhyve</tt> is a hypervisor that runs on the &os;/amd64
 	platform.  At present, it runs &os; (8.x or later), Linux
 	i386/x64, OpenBSD i386/amd64, NetBSD/amd64, Illumos, and
 	Windows Vista/7/8/10/2008r2/2012r2/2016 x64 guests.  Current
 	development is focused on enabling additional guest operating
 	systems and implementing features found in other
 	hypervisors.</p>
 
       <p>A combined <tt>bhyve</tt> and ZFS BoF was held during vBSDCon
 	2015, hosted by Michael Dexter and Allan Jude.  Questions
 	asked about <tt>bhyve</tt> included live migration and
 	suspend/resume support, and configurations using ZFS.</p>
 
       <p>Three <tt>bhyve</tt>-related projects were selected for GSoC
 	2015: NE2000 device emulation, porting <tt>bhyve</tt> to ARM,
 	and ptnetmap support.</p>
 
       <p>The major enhancement for <tt>bhyve</tt> this quarter was
 	support for external firmware, along with a port of the Intel
 	edk2 UEFI firmware.  This allows <tt>bhyve</tt> to run Windows
 	in headless mode, and also Illumos.</p>
     </body>
 
     <help>
       <task>
 	<p>Improve the documentation.</p>
       </task>
 
       <task>
 	<p><tt>bhyveucl</tt> is a work-in-progress script for
 	  starting <tt>bhyve</tt> instances based on a libUCL config
 	  file.  More information at
 	  <a href="https://github.com/allanjude/bhyveucl">https://github.com/allanjude/bhyveucl</a>.</p>
       </task>
 
       <task>
 	<p>Add support for virtio-scsi.</p>
       </task>
 
       <task>
 	<p>Flexible networking backends: wanproxy, vhost-net.</p>
       </task>
 
       <task>
 	<p>Support running <tt>bhyve</tt> as non-root.</p>
       </task>
 
       <task>
 	<p>Add filters for popular VM file formats (VMDK, VHD,
 	  QCOW2).</p>
       </task>
 
       <task>
 	<p>Implement an abstraction layer for video (no X11 or SDL in
 	  base system).</p>
       </task>
 
       <task>
 	<p>Suspend/resume support.</p>
       </task>
 
       <task>
 	<p>Live migration.</p>
       </task>
 
       <task>
 	<p>Nested VT-x support (<tt>bhyve</tt> in <tt>bhyve</tt>).</p>
       </task>
 
       <task>
 	<p>Support for other architectures (ARM, MIPS, PPC).</p>
       </task>
     </help>
   </project>
 
   <project cat='proj'>
     <title>High Availability Clustering in CTL</title>
 
     <contact>
       <person>
 	<name>
 	  <given>Alexander</given>
 	  <common>Motin</common>
 	</name>
 	<email>mav@FreeBSD.org</email>
       </person>
     </contact>
 
     <body>
       <p>CAM Target Layer (CTL), when originally developed by
 	Copan/SGI, had support for High Availability clustering.
 	Unfortunately, significant portions of the HA code were never
 	published with the main body of the source code.  Now, the
 	missing part has been reimplemented from scratch, fixed, and
 	improved.</p>
 
       <p>This code supports dual-node HA with Asynchronous LUN Unit
 	Access (ALUA) in four modes:</p>
 
       <ul>
 	<li>Active/Unavailable without interlink between nodes, where
 	  the secondary node can report nothing except its
 	  presence.</li>
 
 	<li>Active/Standby with the secondary node handling only basic
 	  LUN discovery and reservation, synchronizing state and
 	  command execution with the primary node through the
 	  interlink.</li>
 
 	<li>Active/Active with both nodes processing commands and
 	  accessing the backing storage, synchronizing state and
 	  command execution with the primary node through the
 	  interlink.</li>
 
 	<li>Active/Active with the secondary node having no backing
 	  storage access, but instead working as a proxy, transferring
 	  all commands to the first node for execution through the
 	  interlink.</li>
       </ul>
 
       <p>In the case of lost interlink connectivity to primary node,
 	the secondary node falls into the Transitioning state, which
 	is like Unavailable and cannot answer most requests, but makes
 	the initiator wait for recovery or cluster failover.</p>
 
       <p>CTL also got a large number of other improvements, including
 	support for emulation of CD/DVD drives and removable disks,
 	live LUN reconfiguration, and so on.</p>
 
       <p>The code is committed to &os; head and was recently merged to
 	the stable/10 branch.</p>
     </body>
 
     <sponsor>
       iXsystems, Inc.
     </sponsor>
   </project>
 
   <project cat='proj'>
     <title>ZFS Code Sync with Latest Illumos</title>
 
     <contact>
       <person>
 	<name>
 	  <given>Alexander</given>
 	  <common>Motin</common>
 	</name>
 	<email>mav@FreeBSD.org</email>
       </person>
     </contact>
 
     <body>
       <p>The ZFS codebase received a significant batch of merges, and
 	is now in sync with the latest Illumos.  Among other things, this
 	update includes:</p>
 
       <ul>
 	<li>LZ4 is now the default compression algorithm.</li>
 
 	<li>Improved prefetch for faster send/receive.</li>
 
 	<li>Reduced RAM usage by almost 50% for L2ARC.</li>
 
 	<li>Improved I/O aggregation.</li>
 
 	<li>Fine-grained checksumming in send/receive stream.</li>
 
 	<li>Reduced import time for pools with many datasets.</li>
 
 	<li>Reworked and simplified predictive prefetcher.</li>
       </ul>
 
       <p>The code is committed to &os; head and was recently merged to
 	the stable/10 branch.
       </p>
     </body>
   </project>
 
   <project cat='bin'>
     <title><tt>mandoc</tt> and <tt>roff</tt> Toolchain</title>
 
     <contact>
       <person>
 	<name>
 	  <given>Baptiste</given>
 	  <common>Daroussin</common>
 	</name>
 	<email>bapt@FreeBSD.org</email>
       </person>
     </contact>
 
     <links>
       <url href="https://github.com/n-t-roff/heirloom-doctools">Heirloom
 	doctools</url>
       <url href="http://mdocml.bsd.lv/">mandoc</url>
     </links>
 
     <body>
       <p><tt>mandoc</tt> is a suite of tools for compiling
 	<tt>mdoc</tt>, the <tt>roff</tt> macro language of choice for
 	BSD manual pages.</p>
 
       <p><tt>mandoc</tt> is the default renderer for manpages on
 	&os; head.  This quarter, the <tt>apropos(1)</tt> utility was
 	switched to use <tt>mandoc</tt>'s version, which offers a new
 	database format (in SQLite) bringing more powerful,
 	fine-grained ways to search man pages.</p>
 
       <p>While <tt>mandoc</tt> is very good for man pages, we also
 	provide lots of other documentation in plain <tt>roff</tt>
 	format.  The Heirloom toolchain is being studied to replace
 	<tt>groff</tt> in base.  The Heirloom <tt>nroff</tt> toolchain
 	has multiple benefits: it has very good unicode support and
 	very good compatibility with <tt>groff</tt>.</p>
 
       <p>A great deal of work as been done testing the Heirloom
 	<tt>nroff</tt> toolchain with all the <tt>roff</tt> documents
 	in the base system (including man pages), and upstream has
 	been very proactive in fixing reported bugs.</p>
 
       <p>The <tt>soelim(1)</tt> utility has been replaced with a
 	BSD-licensed version which is good enough to work with all
 	available <tt>roff</tt> toolchains to ease the transition.
 	This version of the <tt>soelim(1)</tt> utility, originally
 	written solely for &os;, is now part of the <tt>mandoc</tt>
 	tool suite.</p>
 
       <p>In coordination with Ingo Schwarze from OpenBSD, the
 	<tt>col(1)</tt> utility has been cleaned up and updated to
 	recognize both SUSv2-style escape-digit and BSD-style
 	escape-control-char sequences in the input stream.</p>
 
       <p>The <tt>checknr(1)</tt> utility has been cleaned up and
 	extended to support modern <tt>roff(7)</tt> macros, including
 	synchronizing code from NetBSD and the Heirloom doctools
 	version.</p>
 
       <p>Many <tt>roff</tt> fixes were made to documentation and man
 	pages, having been discovered while testing the new
 	toolchain.</p>
     </body>
   </project>
 
   <project cat='bin'>
     <title>Updates to GDB</title>
 
     <contact>
       <person>
 	<name>
 	  <given>John</given>
 	  <common>Baldwin</common>
 	</name>
 	<email>jhb@FreeBSD.org</email>
       </person>
     </contact>
 
     <links>
       <url href="https://reviews.FreeBSD.org/D3341">Extend libkvm to
 	support cross-debugging of vmcores</url>
     </links>
 
     <body>
       <p>Support for following children after forks for &os; was
 	implemented and merged upstream to GDB's master branch, and
 	was included in GDB 7.10.</p>
 
       <p>Work has continued on porting <tt>kgdb</tt> to newer
 	<tt>gdb</tt>.  The amd64, i386, powerpc, powerpc64, and
 	sparc64 backends have all been ported and are now available
 	via a new <tt>KGDB</tt> option in the devel/gdb port.</p>
 
       <p>The MD backends for libkvm have been rewritten to support
 	cross-debugging crashdumps, and the <tt>kgdb</tt> targets for
 	amd64 and i386 have been reworked to support cross-debugging.
 	Both i386 and amd64 kgdb binaries have been able to
 	cross-debug the other architecture's vmcores with these
 	changes.  This changeset for libkvm is not yet in the tree,
 	but is awaiting more testing.</p>
     </body>
 
     <help>
       <task>
 	<p>Test the <tt>libkvm</tt> changes on platforms other than
 	  amd64, i386, and powerpc64.</p>
       </task>
 
       <task>
 	<p>Figure out why the powerpc <tt>kgdb</tt> targets are not
 	  able to unwind the stack past the initial frame.</p>
       </task>
 
       <task>
 	<p>Add support for more platforms (arm, mips, aarch64) to
 	  upstream <tt>gdb</tt> for both userland and
 	  <tt>kgdb</tt>.</p>
       </task>
 
       <task>
 	<p>Write a new 1:1-only thread target for &os; that can be
 	  sent upstream.</p>
       </task>
 
       <task>
 	<p>Add support for debugging powerpc vector registers.</p>
       </task>
     </help>
   </project>
 
   <project cat='bin'>
     <title><tt>truss(1)</tt></title>
 
     <contact>
       <person>
 	<name>
 	  <given>John</given>
 	  <common>Baldwin</common>
 	</name>
 	<email>jhb@FreeBSD.org</email>
       </person>
 
       <person>
 	<name>
 	  <given>Bryan</given>
 	  <common>Drewery</common>
 	</name>
 	<email>bdrewery@FreeBSD.org</email>
       </person>
     </contact>
 
     <body>
       <p>The interface between the ABI-specific backends and the
 	<tt>truss</tt> core was refactored, reducing duplicated code.
 	This prompted additional follow-on work to add support for
 	more ABIs, including aarch64 and CloudABI.</p>
 
       <p><tt>ptrace(2)</tt> was extended to return more information
 	about the currently executing system call.  This restored
 	behavior that had been present in a previous version of
 	<tt>truss</tt>: knowing the correct number of arguments for
 	all system calls.</p>
 
       <p>The fork-following support in <tt>truss</tt> was reworked to
 	use native fork following in <tt>ptrace(2)</tt> rather than
 	forking a new <tt>truss</tt> process for each child of a
 	traced process.</p>
 
       <p>Support for decoding more arguments has been added in
 	the last quarter as well.
       </p>
     </body>
 
     <help>
       <task>
 	<p>Create a new <tt>libsysdecode</tt> library to hold shared
 	  code between <tt>truss(1)</tt> and <tt>kdump(1)</tt>.</p>
       </task>
 
       <task>
 	<p>Decode more system call arguments.</p>
       </task>
 
       <task>
 	<p>Add appropriate system call decoding specifications for
 	  <tt>freebsd32</tt> system calls.</p>
       </task>
 
       <task>
 	<p>Implement an ABI for 64-bit Linux binaries under
 	  &os;/amd64.</p>
       </task>
     </help>
   </project>
 
   <project cat='bin'>
     <title><tt>sesutil(8)</tt></title>
 
     <contact>
       <person>
 	<name>
 	  <given>Baptiste</given>
 	  <common>Daroussin</common>
 	</name>
 
 	<email>bapt@FreeBSD.org</email>
       </person>
 
       <person>
 	<name>
 	  <given>Allan</given>
 	  <common>Jude</common>
 	</name>
 
 	<email>allanjude@FreeBSD.org</email>
       </person>
     </contact>
 
     <links>
       <url href="https://en.wikipedia.org/wiki/SCSI_Enclosure_Services">Wikipedia:
 	SCSI Enclosure Services (SES)</url>
     </links>
 
     <body>
       <p><tt>sesutil(8)</tt> was originally created as a more
 	universal way to blink the &quot;locate&quot; LEDs on most
 	hot-swappable drive enclosures.</p>
 
       <p>This work is based on the original SES tools created by
 	Matthew Jacob in 2000, which have been available in the
 	<tt>share/examples</tt> section of the source tree, but were
 	not built by default.</p>
 
       <p>The new utility extends the original code with a number of
 	very useful features:</p>
 
       <ul>
 	<li>Print a map of all objects connected to the SES
 	  controller</li>
 
 	<li>Map device names (<tt>/dev/da5</tt>) to SES slot
 	  number</li>
 
 	<li>Blink the Locate and/or Fault LED of a drive by its SES
 	  slot number or device name</li>
 
 	<li>Check the status of the entire SES controller</li>
       </ul>
     </body>
 
     <sponsor>
       Gandi
     </sponsor>
 
     <sponsor>
       ScaleEngine Inc.
     </sponsor>
 
     <help>
       <task>
 	<p>Test <tt>sesutil(8)</tt> against more hardware.</p>
       </task>
 
       <task>
 	<p>Diagnose an issue where the locate command sometimes
 	  needs to be sent twice to activate the LED.</p>
       </task>
 
       <task>
 	<p>Add support for <tt>libxo</tt> output types.</p>
       </task>
     </help>
   </project>
 
   <project cat='arch'>
     <title>&os; on Cavium ThunderX (arm64)</title>
 
     <contact>
       <person>
 	<name>
 	  <given>Dominik</given>
 	  <common>Ermel</common>
 	</name>
 	<email>der@semihalf.com</email>
       </person>
 
       <person>
 	<name>
 	  <given>Wojciech</given>
 	  <common>Macek</common>
 	</name>
 	<email>wma@semihalf.com</email>
       </person>
 
       <person>
 	<name>
 	  <given>Zbigniew</given>
 	  <common>Bodek</common>
 	</name>
 	<email>zbb@semihalf.com</email>
       </person>
     </contact>
 
     <body>
       <p>Cavium’s ThunderX is a high-performance 64-bit ARMv8 CPU,
 	available in configurations with up to 48 cores per package.
 	ThunderX is the initial reference platform for the &os;/arm64
 	porting effort.</p>
 
       <p>Additional Semihalf-sponsored work on ThunderX support
 	brought brand new features such as:</p>
 
       <ul>
 	<li> Multi-socket operation: &os; now runs on a two-node
 	  ThunderX server board with a total of 96 CPU cores!</li>
 
 	<li>Virtual Networking Interface Card driver: The VNIC driver
 	  consists of 4 elements (BGX, MDIO, and Physical and Virtual
 	  Functions) and is the second driver in &os; to utilize
 	  SR-IOV capabilities.  ThunderX is now able to use built-in
 	  networking interfaces at 1&ndash;40 Gbps.</li>
       </ul>
 
       <p>Moreover, previously introduced functionalities have been
 	improved and committed to HEAD.  This includes:</p>
       <ul>
 	<li>PCIe drivers for both internal and external
 	  controllers</li>
 	<li>ITS (Interrupt Translation Services) fixes</li>
 	<li>Platform-specific changes for ThunderX</li>
 	<li>Various other fixes to the kernel (PCI, UMA, etc.)</li>
       </ul>
 
       <p>The remaining features are being reviewed and will be
 	integrated into HEAD soon.  However, the GENERIC kernel
 	already supports and runs on ThunderX.</p>
     </body>
 
     <sponsor>
       The FreeBSD Foundation
     </sponsor>
 
     <sponsor>
       ARM Ltd.
     </sponsor>
 
     <sponsor>
       Cavium
     </sponsor>
 
     <sponsor>
       Semihalf
     </sponsor>
 
     <help>
       <task>
 	<p>Upstream the remaining features: 2-socket support, VNIC
 	  driver, and PCIe fixes</p>
       </task>
     </help>
   </project>
 
   <project cat='proj'>
     <title>Multipath TCP for &os;</title>
 
     <contact>
       <person>
 	<name>
 	  <given>Nigel</given>
 	  <common>Williams</common>
 	</name>
 	<email>njwilliams@swin.edu.au</email>
       </person>
     </contact>
 
     <links>
       <url href="http://caia.swin.edu.au/urp/newtcp/mptcp/">MPTCP for
 	&os; Project Website</url>
 
       <url href="https://bitbucket.org/nw-swin/caia-mptcp-freebsd/">MPTCP
 	for &os; Source Repository</url>
     </links>
 
     <body>
       <p>Multipath TCP (MPTCP) is an extension to TCP that allows
 	for the use of multiple network interfaces on a standard TCP
 	session.  The addition of new addresses and scheduling of data
 	across them occurs transparently from the perspective of the
 	TCP application.</p>
 
       <p>The goal of this project is to deliver an MPTCP kernel
 	patch that interoperates with the reference MPTCP
 	implementation, along with additional enhancements to aid
 	network research.</p>
 
       <p>The v0.5 patch was released, which is the first patch
 	of the re-written implementation.  We are in the process of
 	documenting the new design and addressing some feedback as
 	provided from the community.</p>
 
       <p>Work has commenced on improved input handling, as the current
 	method of receiving and reassembling segments has been the
 	cause of some instability and stalls during connection
 	shutdown.  This will involve re-using the subflow receive
 	buffers and an upcall to enqueue a MP-layer reassembly task
 	without the need to take a lock on the MP control block.  The
 	improvements should also allow bypassing <tt>mptcp_usrreq</tt>
 	for standard TCP connections.</p>
 
       <p>The MPTCP commit history was synchronized with
 	hg-beta.FreeBSD.org, and we have made the repository available on
 	BitBucket (see links).  Future patch releases will be tagged
 	there.  The tree is now merged with &os; head weekly.  An
 	updated v0.51 patch is ready for release.</p>
     </body>
 
     <sponsor>
       The FreeBSD Foundation
     </sponsor>
 
     <help>
       <task>
 	<p>Release the v0.51 patch.</p>
       </task>
 
       <task>
 	<p>Populate documentation and the issue tracker on the
 	  BitBucket repository.</p>
       </task>
 
       <task>
 	<p>Improvements to receive-side code before further
 	  testing.</p>
       </task>
 
       <task>
 	<p>Prepare a technical report detailing the design of the
 	  current patch.</p>
       </task>
     </help>
   </project>
 
   <project cat='kern'>
     <title>CloudABI: Pure Capabilities Runtime Environment</title>
 
     <contact>
       <person>
 	<name>
 	  <given>Ed</given>
 	  <common>Schouten</common>
 	</name>
 	<email>ed@FreeBSD.org</email>
       </person>
     </contact>
 
     <links>
       <url href="https://github.com/NuxiNL/cloudlibc">CloudABI project
 	page</url>
 
       <url href="https://github.com/NuxiNL/cloudabi-ports">CloudABI
 	Ports Collection</url>
 
       <url href="https://www.youtube.com/watch?v=LTHSZGVvLw4">CloudABI
 	presentation at FrOSCon</url>
     </links>
 
     <body>
       <p>CloudABI is a POSIX-like runtime environment that uses
 	Capsicum as its sole access control mechanism.  CloudABI
 	allows you to develop software that is better hardened against
 	security vulnerabilities, is easier to test, and is easier to
 	migrate across systems.</p>
 
       <p>As of August, all of the kernel modifications that are needed
 	to run CloudABI programs have been integrated into &os; head.
 	After loading the <tt>cloudabi64</tt> kernel module, you can
 	either run CloudABI programs directly from the shell or by
 	using the <tt>cloudabi-run</tt> tool
 	(<tt>sysutils/cloudabi-utils</tt>).  <tt>cloudabi-run</tt>
 	allows you to inject sockets, files, and directories into the
 	launched program in a more structured way.</p>
 
       <p>In the meantime, work has started on developing a Ports
 	Collection that contains cross-compiled utilities and
 	libraries for CloudABI. The intent is that this framework
 	generates native packages for a number of operating systems,
 	making it possible to develop CloudABI applications on any
 	operating system, regardless of whether that operating system
 	actually supports CloudABI.</p>
 
       <p>If you are interested in CloudABI, be sure to go to the
 	project page on GitHub, watch recordings of talks at
 	conferences, or wait for the upcoming edition of the FreeBSD
 	Journal, which will feature an article on CloudABI.</p>
     </body>
 
     <sponsor>
       Nuxi, the Netherlands
     </sponsor>
 
     <help>
       <task>
 	<p>CloudABI is currently only available for amd64.  It would
 	  make sense to port CloudABI to additional architectures like
 	  aarch64.</p>
       </task>
 
       <task>
 	<p>Support for CloudABI has only been integrated into &os;.
 	  If we manage to upstream support for CloudABI into other
 	  operating systems, it should be possible to run the same
 	  binary on multiple operating systems without
 	  recompilation.</p>
       </task>
 
       <task>
 	<p>The CloudABI Ports Collection currently has only 60
 	  packages.  Although these packages already the building blocks of
 	  some interesting software, we are always interested in
 	  expanding.</p>
       </task>
     </help>
   </project>
 
   <project cat='proj'>
     <title>ZFS Support for UEFI Boot/Loader</title>
 
     <contact>
       <person>
 	<name>
 	  <given>Eric</given>
 	  <common>McCorkle</common>
 	</name>
 	<email>eric@metricspace.net</email>
       </person>
     </contact>
 
     <body>
       <p>UEFI-enabled <tt>boot1.efi</tt> and <tt>loader.efi</tt> have
 	been modified to support loading and booting from a ZFS
 	filesystem, as described in the previous report.  The
 	ZFS-enabled <tt>loader.efi</tt> can be treated as a
 	chainloader when using ZFS-enabled GRUB.</p>
 
       <p>During this quarter, several successful tests have been
 	reported on simple ZFS setups, using both <tt>boot1.efi</tt>
 	with <tt>loader.efi</tt> as well as GRUB and
 	<tt>loader.efi</tt>.</p>
 
       <p>Successful tests have been reported for UFS with the
 	patched <tt>boot1.efi</tt> and <tt>loader.efi</tt> as well.
       </p>
     </body>
 
     <help>
       <task>
 	<p>Test reports are needed for more complex ZFS setups,
 	  such as with log/l2arc vdevs, mirroring, striping, and
 	  raidz.</p>
       </task>
 
       <task>
 	<p>Pending successful reports, the patch needs to be
 	  reviewed and committed.</p>
       </task>
     </help>
   </project>
 
   <project cat='gsoc'>
     <title>Allwinner A10/A20 Support</title>
 
     <contact>
       <person>
 	<name>
 	  <given>Luiz Otavio</given>
 	  <common>O Souza</common>
 	</name>
 	<email>loos@FreeBSD.org</email>
       </person>
 
       <person>
 	<name>
 	  <given>Pratik</given>
 	  <common>Singhal</common>
 	</name>
 	<email>ps06756@gmail.com</email>
       </person>
     </contact>
 
     <links>
       <url href="https://wiki.FreeBSD.org/FreeBSD/arm/Allwinner">Wiki
 	page</url>
     </links>
 
     <body>
       <p>The Allwinner A10 and A20 chips are ARM CPUs found in
 	increasingly common development boards and other devices, such as 
 	the Cubieboard/Cubieboard 2 and the Banana Pi.</p>
 
       <p>With the end of a GSoC project by Pratik Singhal, our A10 and
 	A20 support has improved.  Pratik helped with the
 	implementation and testing of the SD card and SATA support for
 	the Allwinner chips.</p>
 
       <p>&a.loos; added support for the <tt>dwc</tt> network interface
 	on the A20, which is capable of gigabit speeds.</p>
 
       <p>&a.gjb; kindly added support for official &os; images for
 	Cubieboard 2 and the Banana Pi.</p>
     </body>
 
     <sponsor>
       Google Summer of Code 2015 (partly)
     </sponsor>
 
     <help>
       <task>
 	<p>Some drivers are still missing: audio,
 	  video/HDMI/framebuffer, IR, I2C, SPI, PWM.</p>
       </task>
 
       <task>
 	<p>Fix <tt>if_dwc</tt> for better performance.</p>
       </task>
     </help>
   </project>
 
   <project cat="proj">
     <title>The <tt>nosh</tt> Project</title>
 
     <contact>
       <person>
 	<name>
 	  <given>Jonathan</given>
 	  <common>de Boyne Pollard</common>
 	</name>
 	<email>J.deBoynePollard-newsgroups@NTLWorld.COM</email>
       </person>
     </contact>
 
     <links>
       <url href="http://homepage.ntlworld.com./jonathan.deboynepollard/Softwares/nosh.html">Introduction
 	and blurb</url>
 
       <url href="http://homepage.ntlworld.com./jonathan.deboynepollard/Softwares/nosh/freebsd-binary-packages.html">&os;
 	binary packages</url>
 
       <url href="http://homepage.ntlworld.com./jonathan.deboynepollard/Softwares/nosh/timorous-admin-installation-how-to.html">Installation
 	How-To</url>
 
       <url href="http://homepage.ntlworld.com./jonathan.deboynepollard/Softwares/nosh/roadmap.html">Roadmap</url>
 
       <url href="http://homepage.ntlworld.com./jonathan.deboynepollard/Softwares/nosh/commands.html">Commands</url>
 
       <url href="http://homepage.ntlworld.com./jonathan.deboynepollard/Softwares/nosh/guide/index.html">A
 	slightly outdated nosh Guide</url>
     </links>
 
     <body>
       <p>The nosh project is a suite of system-level utilities for
 	initializing, running, and shutting down BSD systems, and for
 	managing daemons, terminals, and logging.  It supersedes BSD
 	<tt>init</tt> and the NetBSD <tt>rc.d</tt> system, drawing
 	inspiration from Solaris SMF for named milestones,
 	daemontools-encore for service control/status mechanisms,
 	UCSPI, and IBM AIX for separated service and system
 	management.  It comprises a range of compatibility mechanisms,
 	including shims for familiar commands from other systems, and
 	an automatic import mechanism that takes existing
 	configuration data from <tt>/etc/fstab</tt>,
 	<tt>/etc/rc.conf{,.local}</tt>, <tt>/etc/ttys</tt>, and
 	elsewhere, applying them to its native service definitions and
 	creating additional native services.  It is portable
 	(including to Linux) and composable, it provides a migration
 	path from the world of systemd Linux, and it does not require new
 	kernel APIs.  It provides clean service environments,
 	orderings and dependencies between services, parallelized
 	startup and shutdown (including <tt>fsck</tt>), strictly
 	size-capped and autorotated logging, the service manager as a
 	&quot;subreaper&quot;, and uses <tt>kevent(2)</tt> for
 	event-driven parallelism.</p>
 
       <p>The past few months have seen a growth in the import
 	mechanism, with full import of <tt>/etc/fstab</tt> and
 	<tt>/etc/ttys</tt> available in version 1.18 in July, and
 	importing PC-BSD Warden and &os;&nbsp;9 jails, and full import
 	of <tt>gbde</tt> and <tt>geli</tt> mount/unmount mechanisms in
 	version 1.21 in October.  It has also gained the ability to
 	automatically re-generate <tt>host.conf</tt> and
 	<tt>sysctl.conf</tt> whenever their source files change.</p>
 
       <p>Other developments in the past few months include fully
 	independent shutdown support, no longer relying upon an
 	externally provided shutdown command from another toolset, and
 	a full suite of binary packages.  As of version 1.20, it
 	became possible to have a fully-<tt>nosh</tt>-managed system,
 	on both &os; and Linux, using just precompiled binary
 	packages.</p>
 
       <p>The biggest task remaining is one that was set a while ago:
 	the creation of enough native service bundles and ancillary
 	utilities to entirely supplant the <tt>rc.d</tt> system.  A
 	lot of this has been achieved, with the original target list
 	of 157 items now down to just 39 remaining.  These are the
 	tricky ones, of course, where help is most needed.
       </p>
     </body>
 
     <help>
       <task>
 	<p>There are still a few rc scripts left that should be easy
 	  to convert, such as <tt>/etc/rc.d/gptboot</tt> and
 	  <tt>/etc/rc.d/growfs</tt> as oneshot services,
 	  <tt>/etc/rc.d/routing</tt>, and
 	  <tt>/etc/rc.d/kldxref</tt>.</p>
       </task>
 
       <task>
 	<p>&os;'s <tt>/etc/rc.d/bluetooth</tt> is over 360 lines long.
 	  In 2011, Iain Hibbert wrote a "simpler" <tt>bluetooth</tt>
 	  for NetBSD.  This can perhaps be used as a simpler basis for
 	  a <tt>nosh</tt> translation.</p>
       </task>
 
       <task>
 	<p>Add kernel support for passing a <tt>-b</tt> option to
 	  pid 1, and support for a <tt>boot_bare</tt> variable in the loader,
 	  to allow &quot;emergency&quot; (where even no shell dotfiles
 	  are loaded) and &quot;rescue&quot; mode bootstraps, akin to
 	  Linux.  (History: The <tt>-b</tt> mechanism and idea date
 	  back to version 2.57d of Miquel van Smoorenburg's System 5
 	  init clone, dated 1995-12-03, and was already known as
 	  "emergency boot" by 1997.)</p>
       </task>
 
       <task>
 	<p>Add support to &os;'s <tt>fsck(8)</tt> for outputting
 	  machine-readable progress reports to a designated file
 	  descriptor, so that <tt>nosh</tt> can provide progress bars
 	  for multiple <tt>fsck</tt>s running in parallel.
 	  <tt>nosh</tt> already provides this functionality on Linux,
 	  where <tt>fsck(8)</tt> does provide machine-readable
 	  output.</p>
       </task>
 
       <task>
 	<p>Identify when the configuration import system needs to be
 	  triggered, such as when <tt>bsdconfig</tt> alters
 	  configuration files, and create the necessary hooks to
 	  import external configuration changes into nosh.</p>
       </task>
 
       <task>
 	<p>Investigate how &os;/PC-BSD could be improved by taking
 	  advantage of some available <tt>nosh</tt> package
 	  mechanisms.</p>
       </task>
     </help>
   </project>
 
   <project cat='kern'>
     <title>Adding PCIe Hot-plug Support</title>
 
     <contact>
       <person>
 	<name>
 	  <given>John-Mark</given>
 	  <common>Gurney</common>
 	</name>
 	<email>jmg@FreeBSD.org</email>
       </person>
     </contact>
 
     <links>
       <url href="http://p4db.FreeBSD.org/depotTreeBrowser.cgi?FSPC=//depot/projects/pciehotplug">PCIe
 	Hot-plug Perforce Branch</url>
 
       <url href="https://svnweb.FreeBSD.org/changeset/base/r281874">Commit
-	adding bridge save/restore.</url>
+	adding bridge save/restore</url>
 
       <url href="https://github.com/FreeBSDFoundation/freebsd/tree/pciehp">Github
 	branch with patches</url>
     </links>
 
     <body>
       <p>PCI Express (PCIe) hot-plug is used on both laptops and
 	servers to allow peripheral devices to be added or removed
 	while the system is running.  Laptops commonly include
 	hot-pluggable PCIe as either an ExpressCard slot or a
 	Thunderbolt interface.  ExpressCard has built-in USB support
 	that is already supported by &os;, but ExpressCard PCIe
 	devices like Gigabit Ethernet adapters and eSATA cards are
 	only supported when they are present at boot, and their
 	removal may cause &os; to crash.</p>
 
       <p>The goal of this project is to allow these devices to be
 	inserted and removed while &os; is running.  This work will
 	provide the basic infrastructure to support adding and
 	removing devices, though it is expected that additional work
 	will be needed to update individual drivers to support
 	hot-plug.</p>
 
       <p>Current testing is focused on getting a simple UART device
 	functional.  Basic hot swap is currently functional.</p>
 
       <p>A set of the patches for the work done in this project is
 	now available on github.com.
       </p>
     </body>
 
     <sponsor>
       The FreeBSD Foundation
     </sponsor>
 
     <help>
       <task>
 	<p>Get suspend/resume functional by saving and restoring the
 	  necessary registers.  This should be addressed by
 	  r281874.</p>
       </task>
 
       <task>
 	<p>Make sure that upon suspend, devices are removed so that we
 	  are not fooled if they are replaced with different devices
 	  while the machine is suspended.</p>
       </task>
 
       <task>
 	<p>Improve how state transitions are handled, possibly by
 	  using a proper state machine.</p>
       </task>
     </help>
   </project>
 
   <project cat='proj'>
     <title><tt>automtud</tt>: Better Jumbo Frame Support</title>
 
     <contact>
       <person>
 	<name>
 	  <given>John-Mark</given>
 	  <common>Gurney</common>
 	</name>
 	<email>jmg@FreeBSD.org</email>
       </person>
     </contact>
 
     <links>
       <url href="https://github.com/jmgurney/automtud">jmgurney/automtud
 	on github</url>
     </links>
 
     <body>
       <p>The <tt>automtud</tt> script will allow a &os; machine to
 	send jumbo frames to machines that support them, while using
 	normal-sized frames for other machines.</p>
 
       <p>There are various advantages to using jumbo frames, such as
 	reduced protocol overhead.  It also means that TCP streams
 	will not be segmented as much, although TSO helps mitigate the
 	disadvantages of such segmentation.  In cases where LRO does
 	not work well, fewer packets will be received.</p>
 
       <p>The script currently does not restore the system to its
 	original state when it exits.  This means that you must
 	manually change the interface MTU and delete host routes
 	after stopping the script.
       </p>
     </body>
 
     <help>
       <task>
 	<p>Fix up various Ethernet drivers to better support jumbo
 	  frames.  Most Ethernet drivers, though they support
 	  scatter/gather, use a physically contiguous zone to do so,
 	  which can cause resource shortages.</p>
       </task>
 
       <task>
 	<p>More testing is needed to ensure that things behave as
 	  expected.  This means that when running the script,
 	  communication to all machines functions normally, without
 	  slowdown or connectivity issues.  Check
 	  <tt>vmstat -z | grep mbuf</tt> to ensure that such issues
 	  are not due to running out of <tt>jumbo_9k</tt> or
 	  <tt>jumbo_16k</tt> buffers due to Ethernet driver
 	  issues.</p>
       </task>
     </help>
   </project>
 
   <project cat='gsoc'>
     <title>Update Ficl in Bootloader</title>
 
     <contact>
       <person>
 	<name>
 	  <given>Colin</given>
 	  <common>Lord</common>
 	</name>
 	<email>clord@FreeBSD.org</email>
       </person>
     </contact>
 
     <links>
       <url href="https://wiki.FreeBSD.org/SummerOfCode2015/UpdateFiclInBootloader">Wiki
 	Page</url>
     </links>
 
     <body>
       <p>The &os; bootloader has used Ficl 3 for quite some time.
 	This project was intended to update the version of Ficl in use
 	to Ficl 4.  Ficl 4 is not only faster but also has a smaller
 	memory footprint, both being important advantages for a
 	bootloader.</p>
 
       <p>As part of the Google Summer of Code program, I worked on
 	importing the Ficl 4 sources to get a bootloader running Ficl
 	4. The first half of the summer consisted of setting up my
 	test environment, as well as arranging the sources in the tree
 	properly and modifying the build files to point to the new
 	locations.  Once that was complete, the sources had to be
 	modified to build correctly and to add back in some of the
 	&os;-specific parts from Ficl 3.  Unfortunately, after all
 	those tasks were completed, a few bugs in the Ficl project
 	were discovered that delayed the bootloader update, so it is
 	not finished.  The Illumos project has faced similar issues
 	with Ficl 4 so I received some good tips from them, but since
 	school has started back up I have not been able to put much
 	work into fixing the bugs.</p>
     </body>
 
     <sponsor>
       Google Summer of Code 2015
     </sponsor>
   </project>
 
   <project cat='gsoc'>
     <title><tt>mtree</tt> Parsing and Manipulation Library</title>
 
     <contact>
       <person>
 	<name>
 	  <given>Michal</given>
 	  <common>Ratajsky</common>
 	</name>
 	<email>michal@FreeBSD.org</email>
       </person>
 
       <person>
 	<name>
 	  <given>Brooks</given>
 	  <common>Davis</common>
 	</name>
 	<email>brooks@FreeBSD.org</email>
       </person>
     </contact>
 
     <links>
       <url href="https://wiki.FreeBSD.org/SummerOfCode2015/mtreeParsingLibrary">Wiki
 	page</url>
     </links>
 
     <body>
       <p>&os; includes several programs that work with file system
 	hierarchy descriptions in the <tt>mtree(5)</tt> format.  These
 	descriptions, also called specifications, have a broad range
 	of uses, from automatically creating directory structures to
 	security auditing.</p>
 
       <p> Each of the programs, namely <tt>mtree</tt>,
 	<tt>bsdtar</tt>, <tt>install</tt>, and <tt>makefs</tt>, has
 	its own implementation of the mtree format.  This not only
 	adds maintenance overhead, but also makes interoperability
 	difficult, as each of the implementations only supports a
 	limited subset of the format.</p>
 
       <p>The goal of this project was to create a new
 	<tt>libmtree</tt> library, implementing everything the mtree
 	format has to offer, and wrapping it with an expressive API
 	which all the listed programs can use.  We also wanted
 	<tt>libmtree</tt> to be portable, as one of the major users of
 	the mtree format is <tt>libarchive</tt>, the library
 	implementing most of <tt>bsdtar</tt>.</p>
 
       <p>Currently, the library is functionally complete, ready to be
 	downloaded and receive everyone's attention.  We have also
 	decided to bundle the <tt>mtree</tt> program along with it.
 	The bundled <tt>mtree</tt> has also been modified for better
 	portability.</p>
 
       <p>The project included modifying <tt>libarchive</tt>,
 	<tt>install</tt> and <tt>makefs</tt> to use libmtree.  These
 	modified versions are also available.</p>
 
       <p>Please see the Wiki page for more information, download
 	locations, and an example of using the <tt>libmtree</tt> API.
       </p>
     </body>
 
     <sponsor>
       Google Summer of Code 2015
     </sponsor>
 
     <help>
       <task>
 	<p>Test and review the library code and API, and the
 	  modifications made to the programs.</p>
       </task>
 
       <task>
 	<p>Fix the known problems that are mentioned on the Wiki
 	  page.</p>
       </task>
     </help>
   </project>
 
   <project cat='misc'>
     <title>ZFSguru</title>
 
     <contact>
       <person>
 	<name>
 	  <given>Jason</given>
 	  <common>Edwards</common>
 	</name>
 	<email>jason@zfsguru.com</email>
       </person>
     </contact>
 
     <links>
       <url href="http://zfsguru.com">Home page</url>
 
       <url href="http://zfsguru.com/forum/zfsgurudevelopment/1038">Forum
 	post on Gnome&nbsp;3 debugging</url>
     </links>
 
     <body>
       <p>ZFSguru started as a front-end to ZFS but has since grown
 	into a multifunctional server appliance with its own unique
 	features.  While the project is still in early development, it
 	already offers multiple unique features not found in other
 	projects.  Unlike similar projects, nothing is stripped away
 	from the base operating system, meaning ZFSguru behaves as a
 	normal &os; installation and thus is very versatile.  The
 	web-interface is designed to unite both novice and advanced
 	users, providing both very easy to use basic functionality as
 	well as features to be appreciated by more experienced users.
 	The modular nature of the project combats the danger of bloat,
 	whilst still allowing extended functionality to be easily
 	deployed.</p>
 
       <p>On the 15th of August, version 0.3 of ZFSguru was released.
 	Some highlights of the new version:</p>
 
       <ul>
 	<li>New build infrastructure allows for frequent releases of
 	  system images and services in a semi-automated way.</li>
 
 	<li>A new GuruDB database allows for a growing number of
 	  system images and servers, and provides good caching to
 	  accelerate pages.</li>
 
 	<li>The installation procedure was given a major
 	  overhaul.</li>
 
 	<li>In addition to the LiveCD, USB images are now available.
 	  The USB image supports both legacy MBR bootcode and UEFI
 	  boot.</li>
 
 	<li>Many libraries in the web-interface have been
 	  overhauled, in addition to many other additions to the
 	  web interface.</li>
 
 	<li>Many improvements were made to optional add-on services,
 	  such as the new Gnome 3 graphical environment.</li>
       </ul>
 
       <p>Other progress made in the months July, August, and
 	September:</p>
 
       <ul>
 	<li>System image builds 001, 002, 003, and 004 have been
 	  released for all supported branches: 10.0, 10.1, 10.2, 10.3
 	  (-STABLE), and 11.0 (-CURRENT).</li>
 
 	<li>Work on the 0.4 web-interface has started, which focuses
 	  on improving network support in the web-interface.</li>
 
 	<li>Work on a new visual theme for the web-interface has
 	  started.  The new interface is likely to be included in the
 	  upcoming 0.4 release.</li>
 
 	<li>A new master server is being prepared, which is likely to
 	  be operational in December.</li>
 
 	<li>A new website is being worked on, to be launched the first
 	  of January, 2016.</li>
       </ul>
     </body>
 
     <help>
       <task>
 	<p>The new Gnome&nbsp;3 desktop does not work for everyone
 	  and still has issues.  Anyone capable of diagnosing these
 	  issues can give the Gnome&nbsp;3 LiveCD a try.  Please see
 	  the linked forum thread for more information.</p>
       </task>
 
       <task>
 	<p>Several ports fail to compile with our own build
 	  infrastructure, and require bug reports in order to get
 	  them fixed upstream.</p>
       </task>
 
       <task>
 	<p>A 'State of the Project 2015' is due in Q4, providing an
 	  overview for future development of the project.</p>
       </task>
     </help>
   </project>
 </report>