Index: head/en_US.ISO8859-1/htdocs/news/status/report-2016-10-2016-12.xml =================================================================== --- head/en_US.ISO8859-1/htdocs/news/status/report-2016-10-2016-12.xml (revision 49874) +++ head/en_US.ISO8859-1/htdocs/news/status/report-2016-10-2016-12.xml (revision 49875) @@ -1,1515 +1,1602 @@ October-December 2016
Introduction

This is a draft of the October–December 2016 status report. Please check back after it is finalized, and an announcement email is sent to the &os;-Announce mailing list.

This report covers &os;-related projects between October and December 2016. This is the last of four reports planned for 2016.

The last quarter of 2016 was another productive quarter for the &os; project and community. [...]

Thanks to all the reporters for the excellent work!

The deadline for submissions covering the period from January to March 2017 is April 7, 2017.

?>
team &os; Team Reports proj Projects kern Kernel arch Architectures bin Userland Programs ports Ports doc Documentation misc Miscellaneous &os;/EC2 Colin Percival cperciva@FreeBSD.org

This report covers work since the last &os;/EC2 status report (2015Q1).

&os;/EC2 is now part of the regular &os; release build, with snapshots and releases being automatically uploaded and copied to all available regions. Due to legal restrictions this does not currently include the GovCloud or China (Beijing) regions; anyone wishing to use &os; in those regions is encouraged to contact the author.

The AWS Marketplace reports that approximately 800 users are running roughly 2000 &os; EC2 instances. This does not count the likely significantly larger number of EC2 instances launched "directly" through the EC2 API and Console, but at least places a lower bound on usage.

&os; 11.0-RELEASE shipped with support for the "enhanced networking" support in EC2 C3, C4, R3, I2, D2, and M4 - (excluding m4.16xlarge) instances. This provides significantly - higher network performance than the virtual networking - available on older EC2 instances and with older versions of - &os;.

+ (excluding m4.16xlarge) instances. This provides + significantly higher network performance than the virtual + networking available on older EC2 instances and with older + versions of &os;.

&os; 11.0-RELEASE and later also use indirect segment disk - I/Os, which yield approximately 20% higher throughput with equal or lower - latency, and support the 128-vCPU x1.32xlarge instance - type.

+ I/Os, which yield approximately 20% higher throughput with + equal or lower latency, and support the 128-vCPU x1.32xlarge + instance type.

&os; now supports the Amazon Simple Systems Manager service ("run command").

- Complete a pending reorganization of the accounts used for &os;/EC2 - releases. + Complete a pending reorganization of the accounts used for + &os;/EC2 releases. - Support "second generation enhanced networking" via - the new Elastic Network Adapter found in P2, R4, X1, and + Support "second generation enhanced networking" + via the new Elastic Network Adapter found in P2, R4, X1, and m4.16xlarge instances. Provide tools for improved functionality via the Simple Systems Manager service: Listing installed packages, checking for updates, adding/removing users, [your favourite sysadmin task goes here]. - Add support for EC2's IPv6 networking to the default &os;/EC2 - configuration. + Add support for EC2's IPv6 networking to the default + &os;/EC2 configuration. Continue ongoing interoperability testing between &os;'s NFS client and Amazon Elastic File System (NFS-as-a-service). Sysctl Exporter for Prometheus Ed Schouten ed@FreeBSD.org The Prometheus Project Node Exporter Sysctl Exporter

Prometheus is an Open Source monitoring system that was - originally built at SoundCloud in 2012. Since 2016, this project is - part of the Cloud Native Computing Foundation, together with other - projects like Kubernetes.

+ originally built at SoundCloud in 2012. Since 2016, this + project is part of the Cloud Native Computing Foundation, + together with other projects like Kubernetes.

-

Prometheus scrapes its targets by periodically sending HTTP GET - requests. Targets then respond by sending key-value pairs of metrics - and their sample value. Prometheus has a query language, PromQL, - that can be used to aggregate sample values and specify alerting - conditions. Tools like Grafana can be used to create fancy - dashboards using such queries.

+

Prometheus scrapes its targets by periodically sending HTTP + GET requests. Targets then respond by sending key-value pairs + of metrics and their sample value. Prometheus has a query + language, PromQL, that can be used to aggregate sample values + and specify alerting conditions. Tools like Grafana can be + used to create fancy dashboards using such queries.

The Prometheus project provides a utility called the - node_exporter that gathers basic system metrics and serves them - over HTTP. This utility tends to be rather complex, as it has - to extract metrics from many different sources. On Linux, files - in /proc have no uniform format, meaning that for every - kernel framework a custom collector needs to be written.

+ node_exporter that gathers basic system metrics and serves + them over HTTP. This utility tends to be rather complex, as + it has to extract metrics from many different sources. On + Linux, files in /proc have no uniform format, meaning + that for every kernel framework a custom collector needs to be + written.

On &os; the sitiuation is better, as the data exported - through sysctl is already structured in such a way that - it can easily be translated to Prometheus' metrics format. The - goal of this project is thus to provide a generic exporter for - the entire sysctl tree. Not only does this prevent unnecessary - bloat and indirection, it may also make the life of a kernel - developer a lot easier. One can easily use Prometheus to graph - the occurrence of an event over time by (temporarily) adding a - counter to the kernel.

+ through sysctl is already structured in such a way + that it can easily be translated to Prometheus' metrics + format. The goal of this project is thus to provide a generic + exporter for the entire sysctl tree. Not only does this + prevent unnecessary bloat and indirection, it may also make + the life of a kernel developer a lot easier. One can easily + use Prometheus to graph the occurrence of an event over time + by (temporarily) adding a counter to the kernel.

An initial version of the sysctl exporter has been integrated into the &os; base system in December. It can be run through inetd by uncommenting the example provided in inetd.conf. Unfortunately, this exporter cannot be merged back to &os; 10.x/11.x, as it depends on KBI-breaking changes to sysctl(9).

Are you using Prometheus or are you interested in using it? Be sure to give both Prometheus and this sysctl exporter a try! It would be nice if we created a set of useful alerting - rules and placed those in /usr/share/examples. For example, how - can one use this exporter to monitor the state of GEOM-based - RAID arrays? Is such information even exported through - sysctl? + rules and placed those in /usr/share/examples. For example, + how can one use this exporter to monitor the state of + GEOM-based RAID arrays? Is such information even exported + through sysctl? Prometheus uses a pretty nifty format for exporting - histograms. Histograms are useful for expressing the amount of - time taken to complete certain events (for example, disk + histograms. Histograms are useful for expressing the amount + of time taken to complete certain events (for example, disk operations). Would it be possible to add histograms as native datatypes to sysctl? If so, is there any chance they can be implemented without picking up any kernel locks? &os; on ARM boards Ganbold Tsagaankhuu ganbold@FreeBSD.org &os; on Allwinner (Sunxi) Systems &os; Commit Adding Support for IR Interfaces

The changes necessary to support the Allwinner Consumer IR - interface in &os; have been committed. The receive (RX) side is - supported now and the driver is using the evdev - framework. It was tested on the Cubieboard2 (A20 SoC) using - lirc with dfrobot's simple IR remote controller.

+ interface in &os; have been committed. The receive (RX) side + is supported now and the driver is using the evdev + framework. It was tested on the Cubieboard2 (A20 SoC) using + lirc with dfrobot's simple IR remote controller.

 libarchive Tim Kientzle kientzle@FreeBSD.org Martin Matuska mm@FreeBSD.org Official Libarchive Homepage Libarchive on GitHub

Libarchive is a BSD-licensed archive and compression library originally developed as part of &os;. It supports a wide variety of input and output formats and also includes three command-line tools: bsdcat, bsdcpio and - bsdtar. The &os; tar and cpio + bsdtar. The &os; tar and cpio utilities are taken directly from Libarchive, and many other important utilities like ar, unzip, and the pkg package manager make use of libarchive's functions.

Libarchive development in 2016 has been focusing on bug fixes and code cleanup, including fixing several critical security issues. Automated testing with Travis CI and Jenkins has been - introduced and libarchive has been added to the Google - OSS-Fuzz project. Fuzzing helped detect several hidden problems - like buffer overflows and memory leaks.

+ introduced and libarchive has been added to the + Google OSS-Fuzz project. Fuzzing helped detect several hidden + problems like buffer overflows and memory leaks.

Over the last few months, NFSv4 ACL support for the pax and restricted pax (the default for bsdtar) formats has been completed and merged to &os;-CURRENT. NFSv4 ACL entries can now be stored to and restored from tar archives.

More extensive CI testing with &os; on different platforms - and releases. Currently only 11.0-RELEASE-amd64 gets tested via - an automated Jenkins job. + and releases. Currently only 11.0-RELEASE-amd64 gets tested + via an automated Jenkins job. As every commit to libarchive may influence the build - process of &os; ports, the ability to trigger a (semi-)automated - exp-run for the ports tree would be great. + process of &os; ports, the ability to trigger a + (semi-)automated exp-run for the ports tree would be + great. &os; on Hyper-V and Azure Sepherosa Ziehau sepherosa@gmail.com Hongjiang Zhang honzhan@microsoft.com Dexuan Cui decui@microsoft.com Kylie Liang kyliel@microsoft.com &os; Virtual Machines on Microsoft Hyper-V Supported Linux and &os; Virtual Machines for Hyper-V on Windows

Per-ring polling, multi-packet RNDIS messages, and system RSS integration have been implemented, further optimizing the throughput and latency of the Hyper-V network driver.

Live virtual machine backup is implemented (for now, only for UFS), after the VSS (Volume Shadow Copy Service), which it depends on, was implemented.

PCIe pass-through is implemented, and the patches to - implement NIC SR-IOV are being reviewed on Phabricator.

+ implement NIC SR-IOV are being reviewed on Phabricator.

vDSO support for speeding up gettimeofday(2) is now implemented.

The &os; 11.0 image on Azure (https://azure.microsoft.com/en-us/marketplace/partners/microsoft/FreeBSD110/) is also available now, in addition to the existing 10.3 image.

We fixed an issue where SCSI disks would sometimes fail to - attach, resolving bug 215171 ([Hyper-V] Fail to attach SCSI disk - from LUN 8 on Win2008R2/Win2012/Win2012R2).

+ attach, resolving bug 215171 ([Hyper-V] Fail to attach SCSI + disk from LUN 8 on Win2008R2/Win2012/Win2012R2).

Microsoft Updates to GDB John Baldwin jhb@FreeBSD.org Luca Pizzamiglio luca.pizzamiglio@gmail.com

The port has been updated to GDB 7.12.

7.12 includes additional fixes related to tracing vfork()s. Some of these fixes depend on changes to - ptrace() in the kernel to report a new ptrace stop when - the parent of a vfork() resumes.

+ ptrace() in the kernel to report a new ptrace stop + when the parent of a vfork() resumes.

Support for &os;/mips userland binaries has been committed upstream. These patches, along with support for debugging &os;/mips kernels, should be added to the port soon.

Figure out why the powerpc kgdb targets are not able to unwind the stack past the initial frame. Add support for more platforms (arm, aarch64) to upstream gdb for both userland and kgdb. Add support for debugging powerpc vector registers. Add support for $_siginfo. Implement 'info proc' commands. Implement 'info os' commands. - Debug gdb hangs related to the 'kill' command. + Debug gdb hangs related to the 'kill' + command. LXQt on &os; Olivier Duchateau olivierd@FreeBSD.org Jesper Schmitz Mouridsen jesper@schmitz.computer LXQt Project &os; LXQt Project LXQt Development Repository

LXQt is the Qt port of and the upcoming version of LXDE, the Lightweight Desktop Environment. It is the product of a merge between the LXDE-Qt and Razor-qt projects.

The porting effort remains very much a work in progress: LXQt requires some components of Plasma 5, the new major KDE workspace.

We imported some core components (it was necessary to update to x11/qterminal 0.7.0):

Standalone applications:

We also have updates for:

- Improve support in sysutils/lxqt-admin (especially - date and time settings). + Improve support in sysutils/lxqt-admin + (especially date and time settings). Xfce on &os; &os; Xfce Team xfce@FreeBSD.org &os; Xfce Project &os; Xfce Repository

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.

-

During this quarter, the team has kept these applications up-to-date:

+

During this quarter, the team has kept these applications + up-to-date:

We also follow the unstable releases (available in our experimental repository) of:

Apply the changes discussed in - D8416 (simplify the - MASTER_SITES macro in port Makefiles) + D8416 + (simplify the MASTER_SITES macro in port + Makefiles) Commit the stable panel plugins OpenBSM Christian Brueffer brueffer@FreeBSD.org Robert Watson rwatson@FreeBSD.org TrustedBSD Audit Mailing Mist trustedbsd-audit@TrustedBSD.org OpenBSM: Open Source Basic Security Module (BSM) Audit Implementation OpenBSM on GitHub &os; Audit Handbook Chapter OpenBSM 1.2 alpha 5 announcement DARPA CADETS project

OpenBSM is a BSD-licensed implementation of Sun's Basic - Security Module (BSM) API and file format. It is the user-space - side of the CAPP Audit implementations in &os; and Mac OS X. - Additionally, the audit trail processing tools are expected to - work on Linux.

+ Security Module (BSM) API and file format. It is the + user-space side of the CAPP Audit implementations in &os; and + Mac OS X. Additionally, the audit trail processing tools are + expected to work on Linux.

This quarter saw increased development activity, fueled by - the DARPA CADETS project, resulting in the release of OpenBSM 1.2 - alpha 5. Among this release's changes are the ability to + the DARPA CADETS project, resulting in the release of OpenBSM + 1.2 alpha 5. Among this release's changes are the ability to specify the kernel's maximum audit queue length, sandboxing support for auditreduce(1) and praudit(1) on &os; and other systems that support Capsicum, as well as the addition of event identifiers for more &os; system calls. The - complete list of changes is documented in the NEWS + complete list of changes is documented in the + NEWS file on GitHub. The new release will be merged into &os; HEAD and the supported STABLE branches shortly.

- + Test the new release on different versions of &os;, Mac OS - X, and Linux. In particular, testing on the latest versions of Mac - OS X would be greatly appreciated. + X, and Linux. In particular, testing on the latest versions + of Mac OS X would be greatly appreciated. Fix problems that have been reported via GitHub and the &os; bug tracker. Implement the features mentioned in the TODO list on GitHub. Portions of this work were sponsored by DARPA/AFRL. The &os; Core Team &os; Core Team core@FreeBSD.org -

The major concern for Core during the last quarter of 2016 has - been about maintaining the effectiveness of secteam. The team is - primarily in need of better project management, both to improve - communication generally and to allow the other team members to - concentrate on the technical aspects of handling +

The major concern for Core during the last quarter of 2016 + has been about maintaining the effectiveness of secteam. The + team is primarily in need of better project management, both + to improve communication generally and to allow the other team + members to concentrate on the technical aspects of handling vulnerabilities.

To that end, there has been agreement in principle for either the FreeBSD Foundation or one of the companies that are major &os; users to employ someone specifically in this role.

-

Core confirmed that the new support model would go into effect - with 11.0-RELEASE despite the postponement of the switch to a - packaged base release mechanism. For details of the new support - model, please follow the links from the security +

Core confirmed that the new support model would go into + effect with 11.0-RELEASE despite the postponement of the + switch to a packaged base release mechanism. For details of + the new support model, please follow the links from the + security page of the &os; website.

Core requested the removal of the misc/jive port, on - the grounds that it had no function other than to turn text into - an offensively racist parody. This proved controversial, with - many seeing this as a first step in bowdlerizing the entire ports - tree. That is certainly not Core's intention. Core's aim here is - to help secure the future of the &os; project by making it - welcoming to all contributors, regardless of ethnicity, gender, - sexuality or other improper bases for discrimintation. While - misc/jive may once have been seen as harmless fun, today - the implicit approval implied by having it in the ports tree sends - a message at odds with the project's aims.

+ the grounds that it had no function other than to turn text + into an offensively racist parody. This proved controversial, + with many seeing this as a first step in bowdlerizing the + entire ports tree. That is certainly not Core's intention. + Core's aim here is to help secure the future of the &os; + project by making it welcoming to all contributors, regardless + of ethnicity, gender, sexuality or other improper bases for + discrimintation. While misc/jive may once have been + seen as harmless fun, today the implicit approval implied by + having it in the ports tree sends a message at odds with the + project's aims.

The Marketing team and the associated marketing@FreeBSD.org - mailing list were wound up, due to lack of activity. Messages to - marketing@FreeBSD.org will be forwarded to the - FreeBSD Foundation's marketing team instead.

+ mailing list were wound up, due to lack of activity. Messages + to marketing@FreeBSD.org will be forwarded to the FreeBSD + Foundation's marketing team instead.

-

Core member Allan Jude, who was already the clusteradm liason, - became a full member of clusteradm.

+

Core member Allan Jude, who was already the clusteradm + liason, became a full member of clusteradm.

An emergency correction to the 11.0 release notes was authorised, as it was giving the misleading impression that 802.11n wireless support had only just been added, and this - misapprehension was being repeated in the press. In reality, &os; - has had 802.11n support for many years, and the announcement - should have said that support had been added to many additional - device drivers.

+ misapprehension was being repeated in the press. In reality, + &os; has had 802.11n support for many years, and the + announcement should have said that support had been added to + many additional device drivers.

Discussions about a proposal to improve Unicode support are on-going. &os; is already standards conformant, but the propsal is to switch to a __STDC_ISO_10646_ implementation, similar to what Linux glibc currently uses. Opinions are divided on the technical merits of the new approach.

-

There were the usual quota of queries about licensing and other - legal matters:

+

There were the usual quota of queries about licensing and + other legal matters:

-

During this quarter four new commit bits were awarded. Please - welcome Dexuan Cui, David Bright, Konrad Witaszczyk, and Piotr - Stefaniak. We were sorry to see Edwin Lansing hang up his commit - bits and step down from portmgr.

+

During this quarter four new commit bits were awarded. + Please welcome Dexuan Cui, David Bright, Konrad Witaszczyk, + and Piotr Stefaniak. We were sorry to see Edwin Lansing hang + up his commit bits and step down from portmgr.

 Ports Collection René Ladan portmgr-secretary@FreeBSD.org &os; Ports Management Team portmgr@FreeBSD.org About &os; Ports Contributing to Ports &os; Ports Monitoring Ports Management Team &os; portmgr on Twitter (@FreeBSD_portmgr) &os; Ports Management Team on Facebook &os; Ports Management Team on Google+ -

The Ports Tree has reached the marker of 27,000 ports, with the PR count - risen slightly to around 2,250. Of these PRs, 572 are unassigned. The - last quarter saw 6871 commits by 176 committers. The number of open and - the number of unassigned PRs both increased lightly since last quarter.

+

The Ports Tree has reached the marker of 27,000 ports, with + the PR count risen slightly to around 2,250. Of these PRs, + 572 are unassigned. The last quarter saw 6871 commits by 176 + committers. The number of open and the number of unassigned + PRs both increased lightly since last quarter.

-

Two commit bits were taken in for safe keeping in the last quarter: - jmg after 19 months of inactivity, and edwin at his own request. We - welcomed three new committers: Nikolai Lifanov (lifanov), Jason Bacon, - and Mikhail Pchelin (misha).

+

Two commit bits were taken in for safe keeping in the last + quarter: jmg after 19 months of inactivity, and edwin at his + own request. We welcomed three new committers: Nikolai + Lifanov (lifanov), Jason Bacon, and Mikhail Pchelin + (misha).

-

On the management side, adamw and feld were elected as new portmgr - members, and rene was promoted to full member. feld is already involved in - ports-secteam.

+

On the management side, adamw and feld were elected as new + portmgr members, and rene was promoted to full member. feld + is already involved in ports-secteam.

-

On the infrastructure side, two new USES (lxqt and varnish) were - introduced. Some default versions were also updated: varnish 4 (new), GCC - 4.8 to 4.9, Perl 5.20 to 5.24, and Python 3.4 to 3.5. Two major ports - reached their end-of-life at December 31st and were removed: Perl 5.18 and - Linux Fedora 10 (the default is Linux CentOS 6). Because &os; 9.3, - 10.1, and 10.2 also reached end-of-life, support for those versions was - removed from the Ports Tree.

+

On the infrastructure side, two new USES (lxqt and varnish) + were introduced. Some default versions were also updated: + varnish 4 (new), GCC 4.8 to 4.9, Perl 5.20 to 5.24, and Python + 3.4 to 3.5. Two major ports reached their end-of-life at + December 31st and were removed: Perl 5.18 and Linux Fedora 10 + (the default is Linux CentOS 6). Because &os; 9.3, 10.1, and + 10.2 also reached end-of-life, support for those versions was + removed from the Ports Tree.

-

Some major ports were updated to their latest versions: pkg to - 1.9.4, Firefox to 50.1.0, Firefox-esr to 45.6.0, Chromium to - 54.0.2840.100, and Ruby to 2.1.10 / 2.2.6 / 2.3.3. - www/node was updated to version 7; version 6 was split - off as www/node6 for long-term support.

+

Some major ports were updated to their latest versions: pkg + to 1.9.4, Firefox to 50.1.0, Firefox-esr to 45.6.0, Chromium + to 54.0.2840.100, and Ruby to 2.1.10 / 2.2.6 / 2.3.3. + www/node was updated to version 7; version 6 was + split off as www/node6 for long-term support.

-

Behind the scenes, antoine ran 39 exp-runs to verify package updates, - framework changes, and changes to the base system. bdrewery installed new - package builders and added builds for &os; 11 for mips, mips64, and - armv6. He also improved the balancing, monitoring, automation of the - package builders.

+

Behind the scenes, antoine ran 39 exp-runs to verify package + updates, framework changes, and changes to the base system. + bdrewery installed new package builders and added builds for + &os; 11 for mips, mips64, and armv6. He also improved the + balancing, monitoring, automation of the package builders.

- If you have some spare time, please take up a PR for testing and - committing. + If you have some spare time, please take up a PR for + testing and committing. I2C, GPIO, and SPI support for MinnowBoard Oleksandr Tymoshenko gonzo@FreeBSD.org Blog Post MinnowBoard Website

The Minnowboard is an Atom-based x86 board (Intel E38xx Series SoC) in a maker-friendly form-factor: it provides convenient access to pins that can be used to connect - peripherals using one of the standard buses: GPIO, SPI, or I2C. - These buses are more common in the ARM/MIPS world than in x86, - so while &os; was able to boot just fine, it lacked support for - these buses on the MinnowBoard.

+ peripherals using one of the standard buses: GPIO, SPI, or + I2C. These buses are more common in the ARM/MIPS world than in + x86, so while &os; was able to boot just fine, it lacked + support for these buses on the MinnowBoard.

As of r310645, HEAD support all three buses via ig4(4), bytgpio(4), and intelspi drivers. The ig4(4) and bytgpio(4) changes - were backported to 11-STABLE; intelspi will be MFCed in - couple of weeks.

+ were backported to 11-STABLE; intelspi will be MFCed + in couple of weeks.

 Ceph on &os; Willem Jan Withagen wjw@digiware.nl Ceph Main Site Main Repository My &os; Fork

Ceph is a distributed object store and file system designed to provide excellent performance, reliability and scalability:

I started looking into Ceph because the HAST solution with CARP and ggate did not really do what I was looking for. But I aim to run a Ceph storage cluster of storage nodes that are running ZFS. User stations would be running bhyve on RBD disks that are stored in Ceph.

The &os; build will build most of the tools in Ceph. Note - that the RBD dependant items will not work, since &os; does not - have RBD (yet).

+ that the RBD dependant items will not work, since &os; does + not have RBD (yet).

Most notable progress since the last report:

Build Prerequisites

Compiling and building Ceph is tested on 12-CURRENT with its clang 3.9.0, but 11-RELEASE will probably also work, given experience with clang 3.7.0 from 11-CURRENT. Interestingly, when 12-CURRENT had clang 3.8.0, that did not work as well as either 3.7.0 or 3.9.0..

The clang 3.4 present in 10-STABLE does not have the required capabilities to compile everything.

The following setup will get things running for &os;:

    -
  1. Install bash and link it in /bin
    2. +
  2. + Install bash and link it in /bin +
    3. -
  3. It is no longer necessary to add a definition of - ENODATA to /usr/include/errno.h
    4. - -
  4. Clone the github repo +
  5. + It is no longer necessary to add a definition of + ENODATA to /usr/include/errno.h +
    6. +
  6. + Clone the github repo (http://github.com/wjwithagen/ceph.git) and checkout the - "wip.FreeBSD" branch
    7. - -
  7. Run ./do_FreeBSD.sh to start the build.
    8. + "wip.FreeBSD" branch + +
  8. + Run ./do_FreeBSD.sh to start the build. +

The old build method using automake is no longer used; see the README.FreeBSD for more details.

Parts not (yet) included:

Run integration tests to see if the &os; daemons will work with a Linux Ceph platform. Compile and test the user space RBD (Rados Block Device). This currently works, but testing has been limitted. Investigate and see if an in-kernel RBD device could be developed akin to &os;'s ggate. Investigate the keystore, which could be embedded in the - kernel on Linux, and currently prevents building Cephfs and some - other components. The first question whether it is really - required, or if only KRBD require it. + kernel on Linux, and currently prevents building Cephfs and + some other components. The first question whether it is + really required, or if only KRBD require it. Scheduler information is not used at the moment, because the schedulers work rather differently between &os; and Linux. - But a a certain point in time, this would need some attention in - src/common/Thread.cc. + But a a certain point in time, this would need some attention + in src/common/Thread.cc. Integrate the &os; /etc/rc.d initscripts in the Ceph stack. This helps with testing, but also enables running Ceph on production machines. Build a testcluster and start running some of the teuthology integration tests on it. Design a vitual disk implementation that can be used with bhyve and attached to an RBD image. &os; Release Engineering Team &os; Release Engineering Team re@FreeBSD.org &os; 11.0-RELEASE Announcement &os; 11.0-RELEASE Release Notes &os; Development Snapshots

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.

The &os; Release Engineering Team in concert with the &os; Security Team finalized &os; 11.0-RELEASE. &os; 11.0-RELEASE was announced on October 10, 2016, roughly four weeks after the original schedule.

The &os; Release Engineering Team would like to specifically thank &a.cperciva; and all members of the &os; Security Team for their extra diligence in ensuring that user-facing upgrade paths were properly addressed and documented.

The &os; Foundation The Graphics Stack on &os; &os; Graphics Team FreeBSD-x11@FreeBSD.org Matthew Macy mmacy@nextbsd.org Graphics Stack Roadmap and Supported Hardware Matrix GitHub Repository Ports Development Repository Fork of libudevd-devd Shim Graphics Team Blog

Good progress on graphics support was made during the weeks - around Christmas and the new year with the import of Linux's 4.9 - DRM for i915 and amdgpu into the drm-next - branch of the github repository. The amdgpu KMS - driver is already somewhat usable, with a few major known issues - remaining. It now supports GPUs as far back as Southern Islands - and up to Polaris. The 4.9 update also appears to have fixed a - regression in i915 that was introduced by the 4.8 merge - late this past summer. The drm-next branch now supports the - Intel integrated graphics unit up to Kaby Lake CPUs. To - facilitate out-of-the-box support on CURRENT, most of the - branch-local VM changes were reverted and the graphics fault - routines converted to use pg_populate. This new interface is the - source of a couple of regressions causing panics on i915 and - severe artifacts with amdgpu on integrated GPUs. Mark Johnston - (markj@) has volunteered to analyze these issues. Please show - your support and encouragement to Mark for helping to move this - project towards the finish line.

+ around Christmas and the new year with the import of Linux's + 4.9 DRM for i915 and amdgpu into the + drm-next branch of the github repository. The amdgpu + KMS driver is already somewhat usable, with a few major known + issues remaining. It now supports GPUs as far back as + Southern Islands and up to Polaris. The 4.9 update also + appears to have fixed a regression in i915 that was + introduced by the 4.8 merge late this past summer. The + drm-next branch now supports the Intel integrated graphics + unit up to Kaby Lake CPUs. To facilitate out-of-the-box + support on CURRENT, most of the branch-local VM changes were + reverted and the graphics fault routines converted to use + pg_populate. This new interface is the source of a couple of + regressions causing panics on i915 and severe artifacts with + amdgpu on integrated GPUs. Mark Johnston (markj@) has + volunteered to analyze these issues. Please show your support + and encouragement to Mark for helping to move this project + towards the finish line.

The xserver-mesa-next-udev branch was created for the ports development repository, and holds Mesa 13.0 and fixes for newer AMD GPUs. It uses a fork of the libudev-devd shim, also bringing Mesa closer to Linux upstream. I plan to keep updating drm and amdgpu (for use on my desktop and potentially longer term for GPGPU computations) as well as work with Mark to address the existing bugs in i915 (assuming that two new porters are approved). However, the Linux i915 developers seems to aggressively explore the space of possible implementations and use of Linux internal APIs, making it prohibitively time - consuming to track upstream. I am helping someone to learn the - ropes of how to replay a subset of changes from a Linux + consuming to track upstream. I am helping someone to learn + the ropes of how to replay a subset of changes from a Linux release into &os; in the hope that he will take over the mantle of drm-next i915 maintainer. Assuming the issues listed above are addressed, a port of the linuxkpi, DRM, and KMS drivers for use on standard amd64 CURRENT installations is planned. Together with upgrades to the relevant graphics ports, this will provide experimental support for new AMD and Intel GPUs.

 Wine Gerald Pfeifer gerald@FreeBSD.org David Naylor dbn@FreeBSD.org Wine Homepage Project Page

The stable version of Wine (aka emulators/wine) has seen three maintenance releases in the last half year, and Xinerama support (in case you have more than one screen) and - GNUTLS (helpful for Evernote or World of Warcraft, for example) - are now active by default.

+ GNUTLS (helpful for Evernote or World of Warcraft, for + example) are now active by default.

The development version (aka emulators/wine-devel) has seen steady progress and reached the RC phase of Wine 2.0. - We are looking forward to a new major release soon that combines - the progress of a year of active development with the stability - of a release.

+ We are looking forward to a new major release soon that + combines the progress of a year of active development with the + stability of a release.

Port WoW64 Using LLVM's LLD Linker as &os;'s System Linker Rafael Espíndola rafael.espindola@gmail.com Ed Maste emaste@FreeBSD.org &os; lld Wiki Page &os;/LLD Tracking PR (LLVM Bugzilla)

LLD is the linker in the LLVM family of projects. It is a high-performance linker that supports the ELF, COFF and Mach-O object formats. It aims to be compatible with the common linkers used for each file format. For ELF this is the GNU Binary File Descriptor (BFD) ld and GNU gold. However, LLD's authors are not constrained by strict compatibility where it would hamper performance or desired functionality.

LLD developers made significant progress over the last quarter. With changes committed to both LLD and &os; we reached a major milestone: it is now possible to link the entire &os;/&amd64; base system (kernel and userland world) with LLD.

Now that the base system links with LLD, we have started investigating linking applications in the ports tree with LLD. Through this process we are identifying limitations or bugs in both LLD and a number of &os; ports. With a few work-in-progress patches we can link approximately 95% of the ports collection with LLD on &amd64;.

The &os; Foundation Fix libtool to detect LLD and pass the same command line arguments as for GNU ld and gold. Investigate remaining &amd64; port build failures. Investigate and improve LLD on arm64, i386, arm, and other non-amd64 architectures. Extensive testing. Reproducible Builds in &os; Baptiste Daroussin bapt@FreeBSD.org Ed Maste emaste@FreeBSD.org Base System Reproducible Builds Wiki Page Ports Reproducible Builds Wiki Page Reproducible Builds Website

Reproducible builds are a set of software development practices which create a verifiable path from human readable source code to the binary code used by computers. A build is reproducible if given the same source code, build environment and build instructions, any party can recreate bit-by-bit identical copies of all specified artifacts.

Baptiste Daroussin and Ed Maste attended the second Reproducible Builds Summit last December, in Berin. We discussed issues of common interest to operating system providers, including other BSDs and Linux distributions.

Following the summit, changes were committed to the &os; base system to address outstanding sources of non-reproducibility. It is now possible to build the &os; base system (kernel and userland) completely reproducibly, although it currently requires a few non-default settings.

Approximately 80% of the ports tree builds reproducibly, with a few work in progress patches. Now that the base system can be built reproducibly, focus will move to the ports tree.

The &os; Foundation The Linux Foundation Integrate &os; ports builds into the reprodcible-builds.org continuous integration infrastructure. Integrate reproducible build patches into the ports tree. Investigate sources of non-reproducibility in individual ports. GCC (GNU Compiler Collection) Gerald Pfeifer gerald@FreeBSD.org Andreas Tobler andreast@FreeBSD.org Antoine Brodin antoine@FreeBSD.org GCC Home Page

Long awaited, the update to GCC 4.9 as the default version of GCC in the Ports Collection (lang/gcc port, - USE_GCC=yes in Makefiles) has arrived, up from GCC 4.8. - This brings quite a number of improvements, see https://gcc.gnu.org/gcc-4.9/changes.html + USE_GCC=yes in Makefiles) has arrived, up from GCC + 4.8. This brings quite a number of improvements, see + https://gcc.gnu.org/gcc-4.9/changes.html for details.

lang/gcc49 has moved to the GCC 4.9.4 release which - marks the closure of the GCC 4.9 branch and release series.

+ marks the closure of the GCC 4.9 branch and release + series.

(Yes, this means we should rather get the next version - upgrade for lang/gcc in place soon. That update per se - is straightforward, but any help in addressing the fallout of - broken ports would be great — please let us know if you - want to help!)

+ upgrade for lang/gcc in place soon. That update per + se is straightforward, but any help in addressing the fallout + of broken ports would be great — please let us know if + you want to help!)

lang/gcc6 has been updated first to GCC 6.2 and then GCC 6.3, bringing a fair number of fixes, and should now be finely suitable for production use.

Update lang/gcc (and hence USE_GCC=yes) to GCC 5. Support for AArch64. Mono Mono on &os; team mono@FreeBSD.org Mono Homepage Dotnet Core Homepage Mono Project Page

During the last quarter, many ports within the mono project have been updated:

USES=mono has been extended to allow for easier use of Nuget packages. This extension has been used adopted by FSharp, MonoDevelop and OpenRA.

Work has started on porting the Microsoft's open-sourced Dotnet Core. Thanks to the work of another team, the native components of coreclr and corefx already support &os;, however there is further work required in bootstrapping the build process and compiling the managed code.

Port Dotnet Core. Test patches for Mono. &os;/arm64 Andrew Turner andrew@FreeBSD.org Oleksandr Tymoshenko gonzo@FreeBSD.org &os; arm64 Wiki Entry

Support for accessing floating-point registers has been added. This uses the same KPI as i386 and amd64. This will - allow for handling places where the floating-point state may be - modified, for example when calling into UEFI.

+ allow for handling places where the floating-point state may + be modified, for example when calling into UEFI.

Support for the optional ARMv8 AES instructions was added to - the kernel. This makes use fo the ability to store and restore - the floating point state. Tests have shown a significant - improvement in AES performance on ThunderX hardware.

+ the kernel. This makes use fo the ability to store and + restore the floating point state. Tests have shown a + significant improvement in AES performance on ThunderX + hardware.

The Cortex Strings memcpy and memmove functions have been imported into the kernel. These are optimised implementations of these common functions.

&os; now boots on the SoftIron Overdrive 3000 using ACPI. The needed changes for this have been submitted to phabricator for review. This includes booting with SMP enabled, and all currently supported devices.

Support for the Raspberry Pi 3 has been committed. Most - devices work, with the exception of WiFi and Bluetooth, as these - are attached via an as-yet unsupported SDIO bus.

+ devices work, with the exception of WiFi and Bluetooth, as + these are attached via an as-yet unsupported SDIO bus.

The FreeBSD Foundation ABT Systems Ltd