From 36a6f31de08ef3af25ec48d0a05d317ebb7915ce Mon Sep 17 00:00:00 2001 From: Warren Block Date: Mon, 19 Oct 2015 15:03:57 +0000 Subject: [PATCH] Whitespace-only fixes, translators please ignore. --- .../news/status/report-2015-07-2015-09.xml | 1821 +++++++++-------- 1 file changed, 1001 insertions(+), 820 deletions(-) diff --git a/en_US.ISO8859-1/htdocs/news/status/report-2015-07-2015-09.xml b/en_US.ISO8859-1/htdocs/news/status/report-2015-07-2015-09.xml index 302beac7a5..77542b6060 100644 --- a/en_US.ISO8859-1/htdocs/news/status/report-2015-07-2015-09.xml +++ b/en_US.ISO8859-1/htdocs/news/status/report-2015-07-2015-09.xml @@ -26,13 +26,13 @@ 2015.

The third quarter of 2015 was another productive quarter for - the &os; project and community. [...]

+ the &os; project and community. [...]

Thanks to all the reporters for the excellent work!

The deadline for submissions covering the period from October to December 2015 is January 7, 2016.

- ?> + ?> @@ -107,22 +107,25 @@ Wikipedia article on IOAT + Commit importing ioat(4) -

A new driver, ioat(4), was added to the tree. ioat(4) - supports Intel's I/O Acceleration Technology devices which are found - on some Intel server systems.

+

A new driver, ioat(4), was added to the tree. + ioat(4) supports Intel's I/O Acceleration Technology + devices which are found on some Intel server systems.

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.

+ 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.

Some I/OAT models support more advanced copying modes, like - XOR; these modes are not yet supported in the ioat(4) driver.

+ XOR; these modes are not yet supported in the ioat(4) + driver.

@@ -135,8 +138,8 @@ -

Further testing, especially on a range of device models other - than BDXDE (looking for volunteers here).

+

Further testing, especially on a range of device models + other than BDXDE (looking for volunteers here).

 @@ -176,13 +179,13 @@

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. -

+ 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.

@@ -219,13 +222,13 @@

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 - — they are standard with any kernel that has DTrace, which - is included in the default GENERIC kernels in 10.X and HEAD. -

+ 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 — they are standard with any kernel that has + DTrace, which is included in the default GENERIC kernels in + 10.X and HEAD.

@@ -251,36 +254,36 @@ how to get things working Blog post with links to commits in CURRENT + Backported patch for 10.2-RELEASE

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.

+ 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.

This quarter, this project extended previous work on the - boot process and keyboard driver as well as the smbus(4) driver. - It added three new drivers: ig4(4), cyapa(4), and isl(4).

+ boot process and keyboard driver as well as the + smbus(4) driver. It added three new drivers: + ig4(4), cyapa(4), and isl(4).

Much of the development was originally done in late 2014. - Since then, the patches have been massively improved and merged - into CURRENT, so that all relevant devices work without manual - patching.

+ Since then, the patches have been massively improved and + merged into CURRENT, so that all relevant devices work without + manual patching.

For those who are unable to run CURRENT, there is a backported patch to 10.2-RELEASE.

Thanks to everyone who helped in the process. I couldn't - have done it without you (you know who you are). -

- + have done it without you (you know who you are).

@@ -313,32 +316,41 @@

This project aims to add support for the LiquidIO family of high-performance programmable accellerator 10/40-gigabit - Ethernet network adapters. The currently developed kernel driver - supports CN6640- and CN6880-based PCIe cards, enabling these - features:

+ Ethernet network adapters. The currently developed kernel + driver supports CN6640- and CN6880-based PCIe cards, enabling + these features:

  • A CNNIC API for controlling/interacting with the smart NIC from user and kernel space including:
      -
    • Handling multiple concurrent applications running on the - same device
      • +
    • Handling multiple concurrent applications running on + the same device
      • +
    • Request/reply mechanism for (a)synchronous ordered/unordered communication
      • +
    • Remote memory operations
      • +
    • Device shutdown/reset
    • +
  • A basic NIC module utilizing the CNNIC API and a Cavium-provided NIC firmware. This module provides:
    • Single/multi-queue TX
      • +
    • Hardware TCP/UDP checksum offloading
      • +
    • Large Receive Offload
      • +
    • Promiscous mode
    • +
  • Sysctl-based device statistics and configuration view
    • +
  • Custom firmware loading via user-built modules and &os;'s firmware(9) mechanism.
@@ -346,7 +358,6 @@

The project is currently being developed in house and is being prepared for upstream. We plan on making it available in &os; 11.

- @@ -373,17 +384,16 @@ - &os; 10.2-RELEASE + &os; 10.2-RELEASE announcement - &os; development + + &os; development snapshots - &os; 10.3-RELEASE + + &os; 10.3-RELEASE schedule - &os; 11.0-RELEASE + + &os; 11.0-RELEASE schedule @@ -439,14 +449,14 @@

This summer we have started porting bhyve 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). -

+ 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).

@@ -492,33 +502,35 @@ PR for the new port + Installation guide + GitLab Source Tree

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 - "Wanted Ports" list on the &os; Wiki.

+ features, used by more than 100.000 organizations, including + NASA and Alibaba. It also is a very long-standing entry on + the "Wanted Ports" list on the &os; Wiki.

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.

+ 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.

Because of the number of dependencies — we nearly hit 100 — 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. -

+ 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.

@@ -535,7 +547,8 @@ -

Updating the port to the latest version of the 8.x branch

+

Updating the port to the latest version of the 8.x + branch

 @@ -551,8 +564,11 @@ - &os; Xfce Project - &os; Xfce Repository + &os; Xfce + Project + + &os; + Xfce Repository @@ -566,12 +582,19 @@
  • science/xfce4-equake-plugin 1.3.8
    • +
  • sysutils/xfce4-power-manager 1.5.2
    • +
  • x11/libexo 0.10.7
    • +
  • x11/xfce4-embed-plugin 1.6.0
    • +
  • x11/xfce4-verve-plugin 1.1.0
    • +
  • x11/xfce4-whiskermenu-plugin 1.5.1
    • +
  • x11-wm/xfce4-desktop 4.12.3
    • +
  • www/midori 0.5.11
@@ -579,21 +602,23 @@ experimental repository) of:

    -
  • sysutils/xfce4-panel-switch 1.0.2 (utility to backup - panel layouts)
    • +
  • sysutils/xfce4-panel-switch 1.0.2 (utility to + backup panel layouts)
    • +
  • x11/xfce4-dashboard 0.5.1

In the trunk branch, x11-wm/xfce4-panel - contains a patch to support sysutils/xfce4-panel-switch - (available through the panel preferences).

+ contains a patch to support + sysutils/xfce4-panel-switch (available through the + panel preferences).

Test the new stable release of GLib 2.46.x with the - kqueue/kevent backend enabled (it was disabled with revision r393663. + kqueue/kevent backend enabled (it was disabled with revision + r393663. Currently several features are broken, especially in Thunar, xfce4-panel, and Xfdashboard.

 @@ -616,20 +641,22 @@ Node.js modules + Pre-draft documentation -

Node.js 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.

+

Node.js 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.

The goal of this project is to make it easy to install the - modules available in the npm package - registry.

+ modules available in the + npm package registry.

Currently, the repository contains more than 100 new ports, in particular:

@@ -637,23 +664,26 @@
  • CoffeeScript (a programming language that transcompiles to JavaScript)
    • +
  • node-gyp (allows building Node.js addons, often written in C or C++)
    • +
  • Request (a simplified HTTP client)
-

We have also written several helpers for the porting, available - in our experimental repository. -

+

We have also written several helpers for the porting, + available in our experimental repository.

-

Bring in grunt.js (and modules), the JavaScript task runner.

+

Bring in grunt.js (and modules), the JavaScript + task runner.

 + -

Put more effort into support of node-gyp in the USES - framework

+

Put more effort into support of node-gyp in the + USES framework

 @@ -677,24 +707,23 @@ -

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, the functionality is known as pivot_root. - The reroot project aims to provide similar functionality in - a different, slightly more user-friendly way. +

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, the 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 point of view it is as simple as running reboot -r. 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.

+ 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.

-

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.

+

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.

@@ -703,7 +732,8 @@ - Clang, <tt>llvm</tt>, <tt>lldb</tt>, <tt>compiler-rt</tt> and <tt>libc++</tt> Updated to 3.7.0 + Clang, <tt>llvm</tt>, <tt>lldb</tt>, <tt>compiler-rt</tt> + and <tt>libc++</tt> Updated to 3.7.0 @@ -713,6 +743,7 @@ dim@FreeBSD.org + Ed @@ -720,6 +751,7 @@ emaste@FreeBSD.org + Roman @@ -727,6 +759,7 @@ rdivacky@FreeBSD.org + Davide @@ -737,49 +770,52 @@ - LLVM 3.7.0 Release Notes - Clang 3.7.0 Release Notes - PR 201377 Ports exp-run + LLVM + 3.7.0 Release Notes + Clang 3.7.0 + Release Notes + + PR 201377 Ports + exp-run - -

We have updated clang, llvm, lldb, compiler-rt and libc++ - in base to 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 +

We have updated clang, llvm, lldb, + compiler-rt and libc++ in base to 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 libunwind.

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.

+ 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.

Thanks to &a.emaste; and &a.andrew; for their help with this - import, and thanks to &a.antoine; for several ports exp-runs. -

+ import, and thanks to &a.antoine; for several ports + exp-runs.

During the first ports exp-run, some major problems were - found, one introduced by a clang bug which caused pow() to - generate floating point exceptions in some cases. This in - turn caused libpng to fail to build, and one bug in - libjpeg-turbo, 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.

- + found, one introduced by a clang bug which caused + pow() to generate floating point exceptions in some + cases. This in turn caused libpng to fail to build, + and one bug in libjpeg-turbo, 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.

Commit ports fixes for dependencies of PR 201377. + Test and report issues with the new tool chain. @@ -797,6 +833,7 @@ emaste@freebsd.org + Marcel @@ -809,13 +846,14 @@

A number of UEFI bug fixes were committed over the last quarter, improving compatibility with different UEFI - implementations. - This includes improvements to EFI's vt(4) framebuffer - driver, efifb, 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.

+ implementations. This includes improvements to EFI's + vt(4) framebuffer driver, efifb, 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.

+ Test &os;-CURRENT and &os;-STABLE snapshots on a variety of UEFI implementations. @@ -835,45 +873,47 @@ - Graphics stack roadmap and supported hardware matrix - Graphics stack team blog - Ports development tree on GitHub + Graphics + stack roadmap and supported hardware matrix + + Graphics + stack team blog + + Ports + development tree on GitHub

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 libosmesa port was merged into the Mesa framework.

+ correctly configured. Dual version support was removed. + There is only one mesa version for all supported &os; + versions. The libosmesa port was merged into the Mesa + framework.

Another big item that was included in the Mesa port is OpenCL. There are two GPU-based OpenCL implementations: lang/clover for supported Radeon cards, and - lang/beignet for supported Intel cards (currently only - Ivybridge). - Thanks go to Johannes Dieterich, O. Hartmann, and Koop Mast - for making this happen.

+ lang/beignet for supported Intel cards (currently + only Ivybridge). Thanks go to Johannes Dieterich, O. + Hartmann, and Koop Mast for making this happen.

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.

+ 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.

-

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 — we will not be - able to provide support.

+

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 — we will not be able to provide + support.

We attended two conferences: XDC 2015 in Toronto and - EuroBSDcon 2015 in Stockholm. - Reports will be posted on the blog. -

+ EuroBSDcon 2015 in Stockholm. Reports will be posted on the + blog.

@@ -899,23 +939,23 @@ Foundation website + &os; Journal

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.

+ 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.

Here are some highlights of what we did to help &os; last quarter:

@@ -923,44 +963,41 @@

Anne Dickison and Deb Goodkin attended OSCON to promote &os;.

-

&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.

+

&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.

-

&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.

+

&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.

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.

+ undergraduate and masters levels. Part of this project was + funded by the Foundation.

George planned and ran the DevSummit at vBSDCon 2015.

We were proud to be a sponsor of vBSDCon - 2015, 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; + 2015, 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.

+ 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.

-

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.

+

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.

-

We sponsored Andy Turner to attend Linaro Connect in - San Francisco, Sept 21-25.

+

We sponsored Andy Turner to attend Linaro Connect in San + Francisco, Sept 21-25.

&a.emaste;, our project development director, attended the X.Org Developer's Conference (XDC) in Toronto, Ontario.

@@ -968,54 +1005,51 @@

We sponsored the 2015 nginx Conference and sent &os; community member &a.jhb;.

-

George Neville-Neil continued planning the +

George Neville-Neil continued planning the 2015 - Silicon Valley Vendor Summit, including securing + Silicon Valley Vendor Summit, including securing the venue.

-

&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.

+

&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.

Benedict helped organize, and he and &a.dru; participated in the &os; - Hackathon in the Linuxhotel in Essen, Germany. - It was a successful weekend of fixing bugs and collaborating - with others.

+ Hackathon in the Linuxhotel in Essen, Germany. It was a + successful weekend of fixing bugs and collaborating with + others.

-

&a.dru; taught a &os; class in Berlin, Germany - July 29-31.

+

&a.dru; taught a &os; class in Berlin, Germany July + 29-31.

We were a sponsor of womENcourage - 2015, in Uppsala Sweden, Sept 24-26. - Dru was the moderator for a panel on + 2015, in Uppsala Sweden, Sept 24-26. Dru was the + moderator for a panel on Open Source - as a Career Path. - 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 + as a Career Path. 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.

+ The workshop would be titled "How to Contribute to &os;", and + participants would learn how to contribute documentation to + the Project.

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;.

+ ScaleEngine. We also continued to approach companies to + provide us with testimonials to help promote their use of + &os;.

Anne Dickison rebooted the Faces of &os; series and is working with &os; contributors on writing their stories. @@ -1024,26 +1058,23 @@ channels and with new partnerships.

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. + 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 what published.

-

&a.gibbs; began 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’ve 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’s been a great collaborative effort with community - members, and this will help future classes in being able - to support inexpensive platforms for teaching &os;.

+

&a.gibbs; began 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’ve 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’s + been a great collaborative effort with community members, and + this will help future classes in being able to support + inexpensive platforms for teaching &os;.

Work continued on creating &os; curriculum for a half day - workshop. - Hopefully this will be available in late Spring.

+ workshop. Hopefully this will be available in late + Spring.

We provided legal support for the Project including granting trademark permission for some users and companies who @@ -1051,14 +1082,15 @@ and marketing literature.

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.

+ they would like to see supported in &os;. We also do this to + help connect &os; developers with commercial users to help + facilitate collaboration.

+ +

&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: -

&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:

  • Code cleanup and bug fixes to several parts of the release build code, and finishing adding support for @@ -1066,15 +1098,16 @@ 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.
    • +
  • 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.
    • +
  • With the &os; Cluster Administrators Team, assisted with a number of general updates and enhancements to the &os; infrastructure.
    • -
-

+

@@ -1122,31 +1155,39 @@

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.

+ infrastructure to validate that a number of the network + stack's multiqueue behaviours are functioning as expected.

-

At present, most of this project has been - implemented. It mainly consists of two parts:

+

At present, most of this project has been implemented. It + mainly consists of two parts:

  1. A general mechanism to collect the per-ring per-cpu - statistics that can be used by all NIC drivers, and extensions to - netstat(1) to report these statistics.
    2. + statistics that can be used by all NIC drivers, and + extensions to netstat(1) to report these + statistics. + +
  2. A suite of network stack behavior testing programs that + consists of: -
  3. A suite of network stack behavior testing programs that consists - of:
      -
    • a virtual multiqueue ethernet interface (vme)
      • +
    • a virtual multiqueue ethernet interface + (vme)
      • +
    • a UDP packet generator based on vme
      • +
    • a UDP server based on socket(2)
      • -
    • a TCP client based on lwip and vme
      • + +
    • a TCP client based on lwip and + vme
      • +
    • a TCP server based on socket(2).
-

However, it still needs further refinements to make it suitable for - committing to &os;-HEAD.

+

However, it still needs further refinements to make it + suitable for committing to &os;-HEAD.

@@ -1165,28 +1206,35 @@ - &os; Gnome website - Devel repository - Upstream build bot - USE_GNOME porters-handbook chapter + &os; Gnome + website + + Devel + repository + + Upstream + build bot + + USE_GNOME + porters-handbook chapter

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.

+ 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.

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' - Makefiles was written and committed to the Porter's Handbook.

+ Makefiles was written and committed to the Porter's + Handbook.

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. -

+ ports tree.

@@ -1238,108 +1286,116 @@ -

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.

+

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.

-

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.

+

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.

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 in order to - optimize performance. Unfortunately, there are almost as many - models as architectures. Moreover, some architectures, for - instance 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.

+ speculative execution. More precisely, it specifies the + extent to which the machine may visibly reorder memory + accesses in order to optimize performance. Unfortunately, + there are almost as many models as architectures. Moreover, + some architectures, for instance 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.

However, 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.

+ 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.

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.

&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;.

+ 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;.

One facility of C11 that was missing from &os; atomics - was fences. Fences are bidirectional barrier operations - which could not be expressed by the existing atomic+barrier - accesses. They were added in r285283.

+ was fences. Fences are bidirectional barrier + operations which could not be expressed by the existing + atomic+barrier accesses. They were added in r285283.

Due to the strong memory model implemented by x86 processors, - atomic_load_acq() and atomic_store_rel() can be implemented by - plain load and store instructions with only a compiler barrier. No - additional ordering constraints are required. This simplification - of atomic_store_rel() was done some time ago in r236456. The - atomic_load_acq() 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.

+ atomic_load_acq() and atomic_store_rel() can + be implemented by plain load and store instructions with only + a compiler barrier. No additional ordering constraints are + required. This simplification of atomic_store_rel() + was done some time ago in r236456. The + atomic_load_acq() 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.

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 RMW - 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 data - dependencies. The corresponding optimization was committed in - r284901.

+ 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 RMW 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 + data dependencies. The corresponding optimization was + committed in r284901.

-

The atomic(9) 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.

+

The atomic(9) 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.

-

Some examples of our preemptive fixes to the misuse of atomics - that would only become evident on weakly ordered machines - are:

+

Some examples of our preemptive fixes to the misuse of + atomics that would only become evident on weakly ordered + machines are:

  • A very important lockless algorithm, used in both the - kernel and libc, is the timekeeping functionality implemented in - kern/kern_tc.c and the userspace - __vdso_gettimeofday. This algorithm relied on x86 TSO - behavior. It was fixed in r284178 and r285286.
    • + kernel and libc, is the timekeeping functionality + implemented in kern/kern_tc.c and the userspace + __vdso_gettimeofday. This algorithm relied on x86 + TSO behavior. It was fixed in r284178 and r285286.
  • The kern/kern_intr.c lockless updates to the it_need indicator were corrected in r285607.
  • An issue with - kern/subr_smp.c:smp_rendezvous_cpus() not guaranteeing - the visibility of updates done on other CPUs to the caller was - fixed in r285771.
    • + kern/subr_smp.c:smp_rendezvous_cpus() not + guaranteeing the visibility of updates done on other CPUs to + the caller was fixed in r285771.
  • The pthread_once() implementation was fixed to include missed barriers in r287556.
    • @@ -1383,6 +1439,7 @@ &os; wiki RISC-V + Single user boot log @@ -1429,34 +1486,34 @@

    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.

    + several build-runs were performed at various points in the + past, and broken ports were marked as such at those times.

    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.

    + 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.

    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. -

    + incorrectly marked as broken (leftovers from the old times) + were marked as working, and fewer than 40 ports still have + issues requiring further work.

    -

    The Ports Collection could benefit a lot from more frequent sweeps - targeting Tier-2 systems.

    +

    The Ports Collection could benefit a lot from more frequent + sweeps targeting Tier-2 systems.

    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.

    + much-anticipated cross-building of ports are essential + pieces to bring &os; packages on par with the base system's + support, architecture-wise.

         @@ -1473,11 +1530,11 @@

    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.

    + 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.

    The Code of Conduct was generally well received and elicited numerous comments and suggestions for improvements from the @@ -1487,37 +1544,35 @@ 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.

    + 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.

    -

    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.

    +

    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.

    -

    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.

    +

    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.

    -

    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.

    +

    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.

    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;. -

    + 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;.

    @@ -1540,64 +1595,74 @@ - Ports Collection website + Ports Collection + website + Contributing to the Ports Collection + Port Monitoring service - Team Website + + Team + Website + Blog - Twitter feed + + Twitter + feed + Facebook page + Google+ page -

    As of the end of Q3 the ports tree holds a bit more - than 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.

    +

    As of the end of Q3 the ports tree holds a bit more than + 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.

    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.

    + 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.

    On the management side, no changes were made to the portmgr team during Q3.

    On the QA side, 25 exp-runs were performed to validate sensitive updates or cleanups. Amongst those, the noticeable - changes are the update to pkg 1.6, the automake14 - removal, and several important port updates such as - doxygen to 1.8.10, gnome3 to 3.16, - cmake to 3.3.1, and the Qt4 ports to 4.8.7. The default - jdk was also set to openjdk8. Some infrastructure - changes included the addition of new options helpers: - opt_VARS, opt_VARS_OFF, opt_IMPLIES, - and opt_PREVENTS. Some macros were also removed, such as - UNIQUENAME and LATEST_LINK. -

    + changes are the update to pkg 1.6, the + automake14 removal, and several important port + updates such as doxygen to 1.8.10, gnome3 to + 3.16, cmake to 3.3.1, and the Qt4 ports to 4.8.7. + The default jdk was also set to openjdk8. Some + infrastructure changes included the addition of new options + helpers: opt_VARS, opt_VARS_OFF, + opt_IMPLIES, and opt_PREVENTS. Some macros + were also removed, such as UNIQUENAME and + LATEST_LINK.

    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! -

    + 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!

    @@ -1642,22 +1707,32 @@
    • Many internal distribution systems switched from rsync to a distribution mesh using "syncthing".
      • +
    • We have implemented more code/data signing infrastructure with out-of-band verification.
      • +
    • New 32-core reference build hosts are online.
      • +
    • Internal admbugs switched from bugzilla 4.4 to 5.0 and packages were made available for the bugmeister team.
      • +
    • Finally switched from varnish3 to varnish4.
      • +
    • We exorcised hub.FreeBSD.org, the last survivor of the 2012 security incident.
      • -
    • vuxml and the legacy portaudit build system were converted to - components and integrated.
      • -
    • https://download.FreeBSD.org/ is nearing completion (please - do not use until officially announced).
      • + +
    • vuxml and the legacy portaudit build system were converted + to components and integrated.
      • + +
    • https://download.FreeBSD.org/ is nearing completion + (please do not use until officially announced).
      • +
    • A Taiwan node was brought into service for pkg, ftp, svn, and vuxml mirroring.
      • +
    • One of the freebsd-update mirrors was converted from lighttpd to nginx due to a data corruption bug.
      • +
    • Completed detachment of the svn repository from the old cluster and moved it to its new location.
    @@ -1665,18 +1740,20 @@

    Ongoing:

      -
    • The cluster runs a mixture of 11-current and 10-stable - as part of our "eat our own dogfood" project. For this - to be useful, we do monthly cluster refreshes to keep up with - current code.
      • +
    • The cluster runs a mixture of 11-current and 10-stable as + part of our "eat our own dogfood" project. For + this to be useful, we do monthly cluster refreshes to keep + up with current code.
      • +
    • We build internal base system snapshots every few days and packages every day.
      • +
    • 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.
      • + 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.
    @@ -1693,48 +1770,58 @@ KDE on &os; website + KDE ports staging area + KDE on &os; wiki + KDE/&os; mailing list + Development repository for integrating KDE 5 -

    Overall, we have updated the following ports this quarter:

    +

    Overall, we have updated the following ports this + quarter:

    • CMake 3.3.1 (r396266)
      • +
    • Qt 4.8.7 (r397043)
      • +
    • QtCreator 3.5.0 (r395935)
      • +
    • Fixed some dependencies, typos and plists in Qt5-ports (r396044-r396047), spotted by Ralf Nolden
    -

    In our development repository, we have done the following work:

    +

    In our development repository, we have done the following + work:

    • 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)
      • + bindings 5.5, contributed by Guido Falsi, and modified by + Tobias Berner (area51)
    • Updated qt5 to 5.5.0. Ralf Nolden has contributed a - handful of useful new ports, for example lang/qt5-l10n - (area51/qt-5.5)
      • + handful of useful new ports, for example + lang/qt5-l10n (area51/qt-5.5) -
    • The plasma5 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 (area51/plasma5)
      • +
    • The plasma5 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 + (area51/plasma5)
    -

    Work on getting the stuff from plasma5 branch into ports. - (This is a major update to nearly all KDE applications, so - testers are very welcome.)

    +

    Work on getting the stuff from plasma5 branch into + ports. (This is a major update to nearly all KDE + applications, so testers are very welcome.)

     @@ -1770,12 +1857,13 @@ - &os; arm64 wiki page + &os; arm64 wiki + page -

    Numerous cleanups and fixes have been applied to - the arm64 kernel. This includes fixes to exception handling, +

    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 @@ -1786,9 +1874,10 @@ support for the ARM GICv3 interrupt controllers and fixing the memory mapping to be shareable between CPUs.

    -

    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. +

    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.

    @@ -1821,25 +1910,26 @@ - HiKey wiki entry + HiKey wiki + entry + Hardware description -

    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.

    +

    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.

    -

    &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.

    +

    &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.

    -

    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. -

    +

    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.

    @@ -2006,8 +2096,9 @@ 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.

    + this version of the site was created. Screens have become + larger and wider, and increased in resolution at the same + time.

    It was time for a change. Font sizes were set to percentages, with none smaller than 100%. The width of the @@ -2025,8 +2116,8 @@ -

    Fix other outdated assumptions in the CSS. - Alternately, rework the entire site. However, that is a much more +

    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.

         @@ -2043,41 +2134,56 @@ -

    pkg 1.6.0 has been released. Many changes - have been made since pkg 1.5:

    +

    pkg 1.6.0 has been released. Many changes have been + made since pkg 1.5:

    • The dependency solver is greatly improved
      • +
    • Lots of fixes in the three-way merge code
      • +
    • pkg add can now work without a version specified in the dependency line
      • -
    • pkg check -d now also checks the required libraries
      • + +
    • pkg check -d now also checks the required + libraries
      • +
    • Improved support for partial upgrades
      • +
    • Improved zsh completion support
      • +
    • Improved Linux support: all regression tests now pass on Linux
      • +
    • Messages can now be context aware, showing a given - message always, or only during installation, upgrade (conditional on - previous version), or removal
      • -
    • @keywords now accept new entries to add context-aware messages
      • + message always, or only during installation, upgrade + (conditional on previous version), or removal + +
    • @keywords now accept new entries to add context-aware + messages
      • +
    • Added the ability to generate graphiz's dot format representation of the solver's problem
      • -
    • pkg search now defaults to showing the pkg-comments - of the matched packages
      • + +
    • pkg search now defaults to showing the + pkg-comments of the matched packages
      • +
    • Lots of bug fixes and code cleanup
      • +
    • Improvements in cross-installation support
    -

    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.

    +

    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.

     -

    Investigate replacing openssl by mbedtls.

    +

    Investigate replacing openssl by + mbedtls.

         @@ -2104,30 +2210,33 @@ - &os; PVH DomU wiki - page - &os; PVH Dom0 wiki - page + &os; PVH DomU + wiki page + + &os; PVH Dom0 + wiki page + Porting &os; as a Xen ARM guest

    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.

    + 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.

    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 on adding new features to both &os; and Xen to - have feature parity with traditional PV guests/hosts.

    + 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 on + adding new features to both &os; and Xen to have feature + parity with traditional PV guests/hosts.

    Apart from this, work is ongoing to import a new netfront from Linux in order to support new features, like split event @@ -2145,7 +2254,8 @@ -

    Generalize the event channel code so it can be used on ARM.

    +

    Generalize the event channel code so it can be used on + ARM.

    @@ -2153,7 +2263,8 @@ -

    Work with upstream Xen to improve PVH and make it stable.

    +

    Work with upstream Xen to improve PVH and make it + stable.

     @@ -2213,8 +2324,10 @@ bhyve FAQ and talks NE2000 device emulation GSoC project + Porting bhyve to ARM GSoC project + ptnetmap support in bhyve GSoC project @@ -2222,28 +2335,32 @@

    bhyve 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.

    + 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.

    -

    A combined bhyve and ZFS BoF was held during vBSDCon 2015, - hosted by Michael Dexter and Allan Jude. Questions asked about - bhyve included live migration and suspend/resume support, and - configurations using ZFS.

    +

    A combined bhyve and ZFS BoF was held during vBSDCon + 2015, hosted by Michael Dexter and Allan Jude. Questions + asked about bhyve included live migration and + suspend/resume support, and configurations using ZFS.

    -

    Three bhyve-related projects were selected for GSoC 2015: - NE2000 device emulation, porting bhyve to ARM, and - ptnetmap support.

    +

    Three bhyve-related projects were selected for GSoC + 2015: NE2000 device emulation, porting bhyve to ARM, + and ptnetmap support.

    The major enhancement for bhyve this quarter was support for external firmware, along with a port of the Intel - edk2 UEFI firmware. This allows bhyve to run Windows in headless - mode, and also Illumos.

    + edk2 UEFI firmware. This allows bhyve to run Windows + in headless mode, and also Illumos.

      -
    • Windows support
      • -
    • Illumos support
      • +
    • Windows + support
      • + +
    • Illumos + support
    @@ -2254,9 +2371,9 @@

    bhyveucl is a work-in-progress script for - starting bhyve instances based on a libUCL config file. - More information at https://github.com/allanjude/bhyveucl.

    + starting bhyve instances based on a libUCL config + file. More information at + https://github.com/allanjude/bhyveucl.

     @@ -2278,7 +2395,7 @@

    Implement an abstraction layer for video (no X11 or SDL in - base system).

    + base system).

     @@ -2316,38 +2433,45 @@

    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.

    + published with the main body of the source code. Now, the + missing part has been reimplemented from scratch, fixed, and + improved.

    This code supports dual-node HA with Asynchronous LUN Unit Access (ALUA) in four modes:

    • Active/Unavailable without interlink between nodes, where - the secondary node can report nothing except its presence.
      • -
    • 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.
      • + the secondary node can report nothing except its + presence. + +
    • 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.
      • +
    • Active/Active with both nodes processing commands and - accessing the backing storage, synchronizing state and command - execution with the primary node through the interlink.
      • -
    • 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.
      • + accessing the backing storage, synchronizing state and + command execution with the primary node through the + interlink. + +
    • 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.

    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.

    + 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.

    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.

    The code is committed to &os; head and was recently merged to - the stable/10 branch. -

    + the stable/10 branch.

    @@ -2369,20 +2493,26 @@ -

    The ZFS codebase received a significant batch of merges, and is - now in sync with latest Illumos. Among other things, this update - includes:

    +

    The ZFS codebase received a significant batch of merges, and + is now in sync with latest Illumos. Among other things, this + update includes:

    • LZ4 is now a default compression algorithm.
      • +
    • Improved prefetch for faster send/receive.
      • +
    • Reduced RAM usage by almost 50% for L2ARC.
      • +
    • Improved I/O aggregation.
      • +
    • Fine-grained checksumming in send/receive stream.
      • +
    • Reduced import time for pools with many datasets.
      • +
    • Reworked and simplified predictive prefetcher.
    - +

    The code is committed to &os; head and was recently merged to the stable/10 branch.

    @@ -2410,44 +2540,47 @@

    mandoc is a suite of tools for compiling - mdoc, the roff macro language of choice for BSD - manual pages.

    + mdoc, the roff macro language of choice for + BSD manual pages.

    mandoc is the default renderer for manpages on - &os; head. This quarter, the apropos(1) utility was switched to - use mandoc's version, which offers a new database format (in - SQLite) bringing more powerful, fine-grained ways to search - man pages.

    + &os; head. This quarter, the apropos(1) utility was + switched to use mandoc's version, which offers a new + database format (in SQLite) bringing more powerful, + fine-grained ways to search man pages.

    -

    While mandoc is very good for man pages, we also provide - lots of other documentation in plain roff format. The - Heirloom toolchain is being studied to replace groff in - base. The Heirloom nroff toolchain has multiple benefits: it has - very good unicode support and very good compatibility with - groff.

    +

    While mandoc is very good for man pages, we also + provide lots of other documentation in plain roff + format. The Heirloom toolchain is being studied to replace + groff in base. The Heirloom nroff toolchain + has multiple benefits: it has very good unicode support and + very good compatibility with groff.

    A great deal of work as been done testing the Heirloom - nroff toolchain with all the roff documents in the base system - (including man pages), and upstream has been very proactive in - fixing reported bugs.

    + nroff toolchain with all the roff documents + in the base system (including man pages), and upstream has + been very proactive in fixing reported bugs.

    The soelim(1) utility has been replaced with a - BSD-licensed version which is good enough to work with all available - roff toolchains to ease the transition. This version - of the soelim(1) utility, originally written solely for &os;, is - now part of the mandoc tool suite.

    + BSD-licensed version which is good enough to work with all + available roff toolchains to ease the transition. + This version of the soelim(1) utility, originally + written solely for &os;, is now part of the mandoc + tool suite.

    -

    In coordination with Ingo Schwarze from OpenBSD, the col(1) utility has been cleaned up and updated to +

    In coordination with Ingo Schwarze from OpenBSD, the + col(1) 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.

    -

    The checknr(1) utility has been cleaned up and extended to - support modern roff(7) macros, including synchronizing code from NetBSD - and the Heirloom docutils version.

    +

    The checknr(1) utility has been cleaned up and + extended to support modern roff(7) macros, including + synchronizing code from NetBSD and the Heirloom docutils + version.

    -

    Many roff fixes were made to documentation and man pages, - having been discovered while testing the new toolchain. -

    +

    Many roff fixes were made to documentation and man + pages, having been discovered while testing the new + toolchain.

    @@ -2470,38 +2603,39 @@ -

    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.

    +

    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.

    Work has continued on porting kgdb to newer - gdb. The amd64, i386, powerpc, powerpc64, and sparc64 - backends have all been ported and are now available via a new - KGDB option in the devel/gdb port.

    + gdb. The amd64, i386, powerpc, powerpc64, and + sparc64 backends have all been ported and are now available + via a new KGDB option in the devel/gdb port.

    The MD backends for libkvm have been rewritten to support cross-debugging crashdumps, and the kgdb 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.

    + 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.

    -

    Test the libkvm changes on platforms other than amd64, i386, - and powerpc64.

    +

    Test the libkvm changes on platforms other than + amd64, i386, and powerpc64.

     -

    Figure out why the powerpc kgdb targets are not able to unwind - the stack past the initial frame.

    +

    Figure out why the powerpc kgdb targets are not + able to unwind the stack past the initial frame.

    Add support for more platforms (arm, mips, aarch64) to - upstream gdb for both userland and kgdb.

    + upstream gdb for both userland and + kgdb.

     @@ -2537,20 +2671,21 @@ -

    The interface between the ABI-specific backends and the truss - core was refactored, reducing duplicated code. This prompted - additional follow-on work to add support for more ABIs, including - aarch64 and CloudABI.

    +

    The interface between the ABI-specific backends and the + truss core was refactored, reducing duplicated code. + This prompted additional follow-on work to add support for + more ABIs, including aarch64 and CloudABI.

    -

    ptrace(2) was extended to return more - information about the currently executing system call. This - restored behavior that had been present in a previous version of - truss: knowing the correct number of arguments for all system - calls.

    +

    ptrace(2) was extended to return more information + about the currently executing system call. This restored + behavior that had been present in a previous version of + truss: knowing the correct number of arguments for + all system calls.

    -

    The fork-following support in truss was reworked to use - native fork following in ptrace(2) rather than forking a new truss - process for each child of a traced process.

    +

    The fork-following support in truss was reworked to + use native fork following in ptrace(2) rather than + forking a new truss process for each child of a + traced process.

    Support for decoding more arguments has been added in the last quarter as well. @@ -2559,8 +2694,8 @@ -

    Create a new libsysdecode library to hold shared code - between truss(1) and kdump(1).

    +

    Create a new libsysdecode library to hold shared + code between truss(1) and kdump(1).

     @@ -2608,21 +2743,28 @@ -

    sesutil(8) was originally created as a more universal way to blink the - "locate" LEDs on most hot-swappable drive enclosures.

    +

    sesutil(8) was originally created as a more + universal way to blink the "locate" LEDs on most + hot-swappable drive enclosures.

    -

    This work is based on the original SES tools created by Matthew Jacob in - 2000, which have been available in the share/examples section of the - source tree, but were not built by default.

    +

    This work is based on the original SES tools created by + Matthew Jacob in 2000, which have been available in the + share/examples section of the source tree, but were + not built by default.

    -

    The new utility extends the original code with a number of very useful - features:

    +

    The new utility extends the original code with a number of + very useful features:

      -
    • Print a map of all objects connected to the SES controller
      • -
    • Map device names (/dev/da5) to SES slot number
      • -
    • Blink the Locate and/or Fault LED of a drive by its SES slot number - or device name
      • +
    • Print a map of all objects connected to the SES + controller
      • + +
    • Map device names (/dev/da5) to SES slot + number
      • + +
    • Blink the Locate and/or Fault LED of a drive by its SES + slot number or device name
      • +
    • Check the status of the entire SES controller
    @@ -2686,19 +2828,18 @@ ThunderX is the initial reference platform for the &os;/arm64 porting effort.

    -

    Additional Semihalf-sponsored work on ThunderX support brought brand new features such as:

      -
    • Multi-socket operation: - &os; now runs on a two-node ThunderX server board with a total - of 96 CPU cores!
      • -
    • 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–40 Gbps.
      • +
    • Multi-socket operation: &os; now runs on a two-node + ThunderX server board with a total of 96 CPU cores!
      • + +
    • 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–40 Gbps.

    Moreover, previously introduced functionalities have been @@ -2712,9 +2853,8 @@

The remaining features are being reviewed and will be - integrated into HEAD soon. However, the GENERIC kernel already - supports and runs on ThunderX. -

+ integrated into HEAD soon. However, the GENERIC kernel + already supports and runs on ThunderX.

@@ -2755,8 +2895,9 @@ - MPTCP for &os; - Project Website + MPTCP for + &os; Project Website + MPTCP for &os; Source Repository @@ -2765,12 +2906,13 @@

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.

+ across them occurs transparently from the perspective of the + TCP application.

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.

+ patch that interoperates with the reference MPTCP + implementation, along with additional enhancements to aid + network research.

The v0.5 patch was released, which is the first patch of the re-written implementation. We are in the process of @@ -2778,19 +2920,19 @@ provided from the community.

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 mptcp_usrreq for standard TCP connections.

+ 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 mptcp_usrreq + for standard TCP connections.

The MPTCP commit history was synchronized with hg-beta.FreeBSD.org, and 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. -

+ there. The tree is now merged with &os; head weekly. An + updated v0.51 patch is ready for release.

@@ -2803,17 +2945,18 @@ -

Populate documentation and the issue tracker on the BitBucket - repository.

+

Populate documentation and the issue tracker on the + BitBucket repository.

 -

Improvements to receive-side code before further testing.

+

Improvements to receive-side code before further + testing.

 -

Prepare a technical report detailing the design of the current - patch.

+

Prepare a technical report detailing the design of the + current patch.

 @@ -2834,39 +2977,42 @@ CloudABI project page - CloudABI Ports - Collection + + CloudABI + Ports Collection + CloudABI presentation at FrOSCon -

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.

+

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.

-

As of August, all of the kernel modifications that are needed to - run CloudABI programs have been integrated into &os; head. After - loading the cloudabi64 kernel module, you can +

As of August, all of the kernel modifications that are needed + to run CloudABI programs have been integrated into &os; head. + After loading the cloudabi64 kernel module, you can either run CloudABI programs directly from the shell or by using the cloudabi-run tool - (sysutils/cloudabi-utils). cloudabi-run allows you to - inject sockets, files, and directories into the launched - program in a more structured way.

+ (sysutils/cloudabi-utils). cloudabi-run + allows you to inject sockets, files, and directories into the + launched program in a more structured way.

-

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.

+

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.

-

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.

+

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.

@@ -2882,15 +3028,17 @@

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.

+ 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.

 -

The CloudABI Ports Collection currently has only 60 packages. - Although these packages already the building of some interesting - software, we are always interested in expanding.

+

The CloudABI Ports Collection currently has only 60 + packages. Although these packages already the building of + some interesting software, we are always interested in + expanding.

 @@ -2911,13 +3059,14 @@

UEFI-enabled boot1.efi and loader.efi have been modified to support loading and booting from a ZFS - filesystem, as described in the previous report. The ZFS-enabled - loader.efi can be treated as a chainloader when - using ZFS-enabled GRUB.

+ filesystem, as described in the previous report. The + ZFS-enabled loader.efi can be treated as a + chainloader when using ZFS-enabled GRUB.

During this quarter, several successful tests have been - reported on simple ZFS setups, using both boot1.efi with - loader.efi as well as GRUB and loader.efi.

+ reported on simple ZFS setups, using both boot1.efi + with loader.efi as well as GRUB and + loader.efi.

Successful tests have been reported for UFS with the patched boot1.efi and loader.efi as well. @@ -2927,7 +3076,8 @@

Test reports are needed for more complex ZFS setups, - such as with log/l2arc vdevs, mirroring, striping, and raidz.

+ such as with log/l2arc vdevs, mirroring, striping, and + raidz.

@@ -2959,7 +3109,8 @@ - Wiki page + Wiki + page @@ -2969,11 +3120,11 @@

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.

+ implementation and testing of the SD card and SATA support for + the Allwinner chips.

-

&a.loos; added support for the dwc network - interface on the A20, which is capable of gigabit speeds.

+

&a.loos; added support for the dwc network interface + on the A20, which is capable of gigabit speeds.

&a.gjb; kindly added support for official &os; images for Cubieboard 2 and the Banana Pi.

@@ -2997,6 +3148,7 @@ The <tt>nosh</tt> Project + @@ -3010,12 +3162,17 @@ Introduction and blurb + &os; binary packages + Installation How-To + Roadmap + Commands + A slightly outdated nosh Guide @@ -3026,45 +3183,47 @@ managing daemons, terminals, and logging. It supersedes BSD init and the NetBSD rc.d 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 - /etc/fstab, /etc/rc.conf{,.local}, - /etc/ttys, 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, it does not - require new kernel APIs. It provides clean service environments, - orderings and dependencies between services, parallelized startup - and shutdown (including fsck), strictly size-capped and - autorotated logging, the service manager as a - "subreaper", and uses kevent(2) for event-driven - parallelism.

+ 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 /etc/fstab, + /etc/rc.conf{,.local}, /etc/ttys, 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, it does not require new + kernel APIs. It provides clean service environments, + orderings and dependencies between services, parallelized + startup and shutdown (including fsck), strictly + size-capped and autorotated logging, the service manager as a + "subreaper", and uses kevent(2) for + event-driven parallelism.

The past few months have seen a growth in the import mechanism, with full import of /etc/fstab and - /etc/ttys available in version 1.18 in July, and importing - PC-BSD Warden and &os; 9 jails, and full import of gbde and - geli mount/unmount mechanisms in version 1.21 in October. - It has also gained the ability to automatically re-generate - host.conf and sysctl.conf whenever their source - files change.

+ /etc/ttys available in version 1.18 in July, and + importing PC-BSD Warden and &os; 9 jails, and full import + of gbde and geli mount/unmount mechanisms in + version 1.21 in October. It has also gained the ability to + automatically re-generate host.conf and + sysctl.conf whenever their source files change.

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-nosh-managed system, on both &os; and Linux, using just - precompiled binary packages.

+ 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-nosh-managed system, + on both &os; and Linux, using just precompiled binary + packages.

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 rc.d 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. + 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.

@@ -3073,45 +3232,49 @@

There are still a few rc scripts left that should be easy to convert, such as /etc/rc.d/gptboot and /etc/rc.d/growfs as oneshot services, - /etc/rc.d/routing, and /etc/rc.d/kldxref.

+ /etc/rc.d/routing, and + /etc/rc.d/kldxref.

&os;'s /etc/rc.d/bluetooth is over 360 lines long. - In 2011, Iain Hibbert wrote a "simpler" bluetooth for - NetBSD. This can perhaps be used as a simpler basis for a nosh - translation.

+ In 2011, Iain Hibbert wrote a "simpler" bluetooth + for NetBSD. This can perhaps be used as a simpler basis for + a nosh translation.

Add kernel support for passing a -b option to - pid 1, and support for a boot_bare variable in the loader, to - allow "emergency" (where even no shell dotfiles are - loaded) and "rescue" mode bootstraps, akin to Linux. - (History: The -b 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.)

+ pid 1, and support for a boot_bare variable in the loader, + to allow "emergency" (where even no shell dotfiles + are loaded) and "rescue" mode bootstraps, akin to + Linux. (History: The -b 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.)

Add support to &os;'s fsck(8) for outputting - machine-readable progress reports to a designated file descriptor, - so that nosh can provide progress bars for multiple fscks running - in parallel. nosh already provides this functionality on Linux, - where fsck(8) does provide machine-readable output.

+ machine-readable progress reports to a designated file + descriptor, so that nosh can provide progress bars + for multiple fscks running in parallel. + nosh already provides this functionality on Linux, + where fsck(8) does provide machine-readable + output.

Identify when the configuration import system needs to be - triggered, such as when bsdconfig alters configuration - files, and create the necessary hooks to import external - configuration changes into nosh.

+ triggered, such as when bsdconfig alters + configuration files, and create the necessary hooks to + import external configuration changes into nosh.

Investigate how &os;/PC-BSD could be improved by taking - advantage of some available nosh package mechanisms.

+ advantage of some available nosh package + mechanisms.

 @@ -3132,27 +3295,31 @@ PCIe Hot-plug Perforce Branch + Commit adding bridge save/restore. + Github branch with patches

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 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.

+ 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 + 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.

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.

+ 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.

Current testing is focused on getting a simple UART device functional. Basic hot swap is currently functional.

@@ -3168,14 +3335,15 @@ -

Get suspend/resume functional by saving and restoring the necessary - registers. This should be addressed by r281874.

+

Get suspend/resume functional by saving and restoring the + necessary registers. This should be addressed by + r281874.

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.

+ are not fooled if they are replaced with different devices + while the machine is suspended.

 @@ -3204,12 +3372,12 @@ -

The automtud script will allow a &os; machine to send - jumbo frames to machines that support them, while using +

The automtud script will allow a &os; machine to + send jumbo frames to machines that support them, while using normal-sized frames for other machines.

-

There are various advantages to using jumbo frames, - such as reduced protocol overhead. It also means that TCP streams +

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.

@@ -3223,19 +3391,21 @@ -

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.

+

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.

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 vmstat -z | grep mbuf to ensure that - such issues are not due to running out of jumbo_9k or jumbo_16k - buffers due to Ethernet driver issues.

+ expected. This means that when running the script, + communication to all machines functions normally, without + slowdown or connectivity issues. Check + vmstat -z | grep mbuf to ensure that such issues + are not due to running out of jumbo_9k or + jumbo_16k buffers due to Ethernet driver + issues.

 @@ -3266,19 +3436,19 @@ bootloader.

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. -

+ 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.

@@ -3315,29 +3485,29 @@

&os; includes several programs that work with file system hierarchy descriptions in the mtree(5) format. These - descriptions, also called specifications, have a broad range of - uses, from automatically creating directory structures to security - auditing.

+ descriptions, also called specifications, have a broad range + of uses, from automatically creating directory structures to + security auditing.

Each of the programs, namely mtree, - bsdtar, install, and makefs, - has its own implementation of the mtree format. This not only + bsdtar, install, and makefs, 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.

+ difficult, as each of the implementations only supports a + limited subset of the format.

The goal of this project was to create a new libmtree 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 libmtree - to be portable, as one of the major users of the mtree format is - libarchive, the library implementing most of - bsdtar.

+ format has to offer, and wrapping it with an expressive API + which all the listed programs can use. We also wanted + libmtree to be portable, as one of the major users of + the mtree format is libarchive, the library + implementing most of bsdtar.

-

Currently, the library is functionally complete, ready to - be downloaded and receive everyone's attention. We have also - decided to bundle the mtree program along with it. The - bundled mtree has also been modified for better +

Currently, the library is functionally complete, ready to be + downloaded and receive everyone's attention. We have also + decided to bundle the mtree program along with it. + The bundled mtree has also been modified for better portability.

The project included modifying libarchive, @@ -3355,8 +3525,8 @@ -

Test and review the library code and API, and the modifications - made to the programs.

+

Test and review the library code and API, and the + modifications made to the programs.

 @@ -3381,6 +3551,7 @@ Home page + Forum post on Gnome 3 debugging @@ -3388,33 +3559,40 @@

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 + 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.

+ 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.

-

On the 15th of August, version 0.3 of ZFSguru was released. Some - highlights of the new version:

+

On the 15th of August, version 0.3 of ZFSguru was released. + Some highlights of the new version:

  • New build infrastructure allows for frequent releases of system images and services in a semi-automated way.
    • -
  • A new GuruDB database allows for a growing number of system - images and servers, and provides good caching to accelerate - pages.
    • + +
  • A new GuruDB database allows for a growing number of + system images and servers, and provides good caching to + accelerate pages.
    • +
  • The installation procedure was given a major overhaul.
    • +
  • In addition to the LiveCD, USB images are now available. - The USB image supports both legacy MBR bootcode and UEFI boot.
    • / + The USB image supports both legacy MBR bootcode and UEFI + boot./ +
  • Many libraries in the web-interface have been overhauled, in addition to many other additions to the web interface.
    • +
  • Many improvements were made to optional add-on services, such as the new Gnome 3 graphical environment.
@@ -3426,13 +3604,17 @@
  • 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).
    • +
  • Work on the 0.4 web-interface has started, which focuses on improving network support in the web-interface.
    • +
  • 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.
    • -
  • A new master server is being prepared, which is likely to be - operational in December.
    • + started. The new interface is likely to be included in the + upcoming 0.4 release. + +
  • A new master server is being prepared, which is likely to + be operational in December.
    • +
  • A new website is being worked on, to be launched the first of January, 2016.
    • @@ -3441,9 +3623,9 @@

    The new Gnome 3 desktop does not work for everyone - and still has issues. Anyone capable of diagnosing these issues - can give the Gnome 3 LiveCD a try. Please see the linked - forum thread for more information.

    + and still has issues. Anyone capable of diagnosing these + issues can give the Gnome 3 LiveCD a try. Please see + the linked forum thread for more information.

     @@ -3458,5 +3640,4 @@     -