From 9c9ffb40034776c08e7c404b3e73ffe4b88656d6 Mon Sep 17 00:00:00 2001 From: Warren Block Date: Sun, 31 Jan 2016 22:49:41 +0000 Subject: [PATCH] Whitespace-only fixes, translators please ignore. --- .../news/status/report-2015-10-2015-12.xml | 2287 +++++++++-------- 1 file changed, 1180 insertions(+), 1107 deletions(-) diff --git a/en_US.ISO8859-1/htdocs/news/status/report-2015-10-2015-12.xml b/en_US.ISO8859-1/htdocs/news/status/report-2015-10-2015-12.xml index 98fc6ec511..1774e9e40c 100644 --- a/en_US.ISO8859-1/htdocs/news/status/report-2015-10-2015-12.xml +++ b/en_US.ISO8859-1/htdocs/news/status/report-2015-10-2015-12.xml @@ -16,9 +16,9 @@ Introduction

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

+ status report. Please check back after it is finalized, and + an announcement email is sent to the &os;-Announce mailing + list.

This report covers &os;-related projects between October and @@ -26,13 +26,13 @@ 2015.

The fourth 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 January to March 2016 is April 7, 2016.

- ?> + ?> @@ -84,7 +84,8 @@ - Linux Kernel as a Library Added to the Ports Collection + Linux Kernel as a Library Added to the Ports + Collection @@ -102,10 +103,10 @@

LKL ("Linux Kernel as a Library") is a special - "architecture" of the full Linux kernel that builds as a - userspace library on various platforms, including &os;. One - application of such a library is using Linux filesystem drivers - to implement a FUSE backend.

+ "architecture" of the full Linux kernel that builds + as a userspace library on various platforms, including &os;. + One application of such a library is using Linux filesystem + drivers to implement a FUSE backend.

fusefs-lkl's lklfuse binary is such a FUSE filesystem. It can mount ext4/3/2, XFS, and @@ -119,7 +120,8 @@ - <tt>style(9)</tt> Enhanced to Allow C99 <tt>bool</tt> + <tt>style(9)</tt> Enhanced to Allow C99 + <tt>bool</tt> @@ -146,8 +148,8 @@

Use of bool is now allowed. It was allowed - previously, as well, but now it is really allowed. Party - like it's 1999!

+ previously, as well, but now it is really allowed. + Party like it's 1999!

@@ -156,7 +158,8 @@ -

Specify style(9)'s opinion on iso646.h.

+

Specify style(9)'s opinion on + iso646.h.

 @@ -201,15 +204,16 @@ -

Support was added for fixed-width sysctls - (signed and unsigned 8-bit, 16-bit, 32-bit, and 64-bit integers). - The new KPIs are documented in the sysctl(9) manual page. - The sysctl(8) command line tool supports all of the new - types.

+

Support was added for fixed-width sysctls (signed and + unsigned 8-bit, 16-bit, 32-bit, and 64-bit integers). The new + KPIs are documented in the sysctl(9) manual page. + The sysctl(8) command line tool supports all of the + new types.

-

sysctl(8) gained the -t flag, which prints sysctl type - information (the original patch was submitted by Yoshihiro Ota). - This support includes the newly added fixed-width types.

+

sysctl(8) gained the -t flag, which prints + sysctl type information (the original patch was submitted by + Yoshihiro Ota). This support includes the newly added + fixed-width types.

@@ -236,17 +240,16 @@ -

I/OAT DMA engines are bulk memory operation offload - engines built into some Intel Server/Storage platform - CPUs.

+

I/OAT DMA engines are bulk memory operation offload engines + built into some Intel Server/Storage platform CPUs.

-

Several enhancements were made to the driver. - It now avoids memory allocation in locked paths, which - should avoid deadlocking in memory pressure scenarios. Support - for Broadwell-EP devices has been added. The +

Several enhancements were made to the driver. It now avoids + memory allocation in locked paths, which should avoid + deadlocking in memory pressure scenarios. Support for + Broadwell-EP devices has been added. The "blockfill" operation and a non-contiguous 8 KB copy - operation have been added to the API. The driver can recover from - various programming errors by resetting the hardware.

+ operation have been added to the API. The driver can recover + from various programming errors by resetting the hardware.

@@ -255,13 +258,15 @@ -

XOR and other advanced ("RAID") operation support.

+

XOR and other advanced ("RAID") operation + support.

 - <tt>ntb_hw(4)</tt>/<tt>if_ntb(4)</tt> Driver Synced up to Linux + <tt>ntb_hw(4)</tt>/<tt>if_ntb(4)</tt> Driver Synced up to + Linux @@ -279,16 +284,17 @@ -

ntb_hw(4) is now up-to-date with the Linux NTB driver as - of the work-in-progress 4.4 kernel (and actually, contains some - fixes that haven't landed in the mainline Linux tree yet but will - land in 4.5). Only Back-to-back ("B2B") configurations - are supported at this time. Going forward, newer hardware may - only support the B2B configuration.

+

ntb_hw(4) is now up-to-date with the Linux NTB + driver as of the work-in-progress 4.4 kernel (and actually, + contains some fixes that haven't landed in the mainline Linux + tree yet but will land in 4.5). Only Back-to-back + ("B2B") configurations are supported at this time. + Going forward, newer hardware may only support the B2B + configuration.

-

if_ntb(4) is mostly up-to-date with the Linux NTB netdevice - driver. Notably absent is support for changing the MTU at - runtime.

+

if_ntb(4) is mostly up-to-date with the Linux NTB + netdevice driver. Notably absent is support for changing the + MTU at runtime.

@@ -298,8 +304,8 @@

Improving if_ntb(4) to avoid using the entire Base - Address Register (BAR) when very large BAR sizes are configured - (e.g., 512 GB).

+ Address Register (BAR) when very large BAR sizes are + configured (e.g., 512 GB).

 @@ -337,13 +343,12 @@ -

We made the changes required to support the - Amlogic Meson Ethernet controller on the Hardkernel ODROID-C1 - board, which has an Amlogic aml8726-m8b SoC. The main effort - needed was to write a glue driver for the Ethernet controller - — the Amlogic Meson Ethernet controller is compatible with - Synopsys DesignWare 10/100/1000 Ethernet MAC - (if_dwc).

+

We made the changes required to support the Amlogic Meson + Ethernet controller on the Hardkernel ODROID-C1 board, which + has an Amlogic aml8726-m8b SoC. The main effort needed was to + write a glue driver for the Ethernet controller — the + Amlogic Meson Ethernet controller is compatible with Synopsys + DesignWare 10/100/1000 Ethernet MAC (if_dwc).

 @@ -369,16 +374,16 @@

The Mellanox &os; team is proud to announce support for the ConnectX-4 series of network cards in &os; 11-current and &os; 10-stable. These devices deliver top performance, with up to - 100GBit/s of raw transfer capacity, and support both Ethernet and - Infiniband. Currently, the Ethernet driver is ready for use and - the Infiniband support for ConnectX-4 is making good progress. We - hope that it will be complete before &os; 11.0 is released. For - more technical information, refer to the mlx5en(4) manual - page in 11-current. The new driver for ConnectX-4 cards is called - mlx5 and is put under /sys/dev and not under - /sys/ofed as was done for the previous - mlx4 driver. The mlx5en(4) kernel module is - compiled by default in GENERIC kernels.

+ 100GBit/s of raw transfer capacity, and support both Ethernet + and Infiniband. Currently, the Ethernet driver is ready for + use and the Infiniband support for ConnectX-4 is making good + progress. We hope that it will be complete before &os; 11.0 + is released. For more technical information, refer to the + mlx5en(4) manual page in 11-current. The new driver + for ConnectX-4 cards is called mlx5 and is put under + /sys/dev and not under /sys/ofed as was done + for the previous mlx4 driver. The mlx5en(4) + kernel module is compiled by default in GENERIC kernels.

@@ -406,16 +411,16 @@

FreeBSD Mastery: Specialty Filesystems is now in - copyediting. The ebook should be available by the end of January - at all major vendors, and the print in February.

+ copyediting. The ebook should be available by the end of + January at all major vendors, and the print in February.

The book covers everything from removable media, to FUSE, NFSv4 ACLs, iSCSI, CIFS, and more.

If you act really quickly, you can get the electronic early - access version at a 10% discount. You will get the final ebook when - it comes out as well. (This offer evaporates when the final - version comes out.)

+ access version at a 10% discount. You will get the final + ebook when it comes out as well. (This offer evaporates when + the final version comes out.)

@@ -437,20 +442,21 @@ -

The KGDB option is now on by default in the devel/gdb - port.

+

The KGDB option is now on by default in the + devel/gdb port.

-

Changes to support cross-debugging of crashdumps in - libkvm were committed to HEAD in r291406.

+

Changes to support cross-debugging of crashdumps in libkvm + were committed to HEAD in r291406.

A new thread target for &os; that is suitable for merging - upstream has been written and lightly tested. However, it is not - yet available as an option in the port. This thread target uses - ptrace(2) directly rather than libthread_db and - as such supports threads on all ABIs (such as &os;/i386 binaries - on &os;/amd64 and possibly Linux binaries, though that is not yet - tested). It also requires less-invasive changes in the MD targets - in GDB compared to the libthread_db-based target.

+ upstream has been written and lightly tested. However, it is + not yet available as an option in the port. This thread + target uses ptrace(2) directly rather than + libthread_db and as such supports threads on all ABIs + (such as &os;/i386 binaries on &os;/amd64 and possibly Linux + binaries, though that is not yet tested). It also requires + less-invasive changes in the MD targets in GDB compared to the + libthread_db-based target.

@@ -469,7 +475,8 @@

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

+ upstream gdb for both userland and + kgdb.

 @@ -496,9 +503,9 @@ -

iMX.6 is a family of SoC used in multiple hobbyist ARM - boards such as the Hummingboard, RIoTboard, and Cubox. Most of - these products have HDMI output, but until recently, &os; did not +

iMX.6 is a family of SoC used in multiple hobbyist ARM boards + such as the Hummingboard, RIoTboard, and Cubox. Most of these + products have HDMI output, but until recently, &os; did not benefit from it. As of r292574, there is basic video output support so you can use the console on iMX6-based boards and probably run Xorg (not yet tested).

@@ -521,7 +528,8 @@ - Touchscreen Support for Raspberry Pi and Beaglebone Black + Touchscreen Support for Raspberry Pi and Beaglebone + Black @@ -541,17 +549,17 @@

There are two working proof-of-concept drivers for the - AM335x touchscreen and for the official Raspberry Pi's touchscreen - LCD.

- + AM335x touchscreen and for the official Raspberry Pi's + touchscreen LCD.

+

Proper touchscreen support would consist of a userland event reading API, a kernel event reporting API, and kernel hardware - drivers for specific devices. There is an ongoing effort to port - the Linux evdev API to &os; so applications that use libraries like - libinput or tslib could be used without any major changes. Since - it is not yet complete, I created a naive evdev-like API for both - kernel and tslib and was able to run a demo on a Beaglebone Black - with 4DCAPE-43T.

+ drivers for specific devices. There is an ongoing effort to + port the Linux evdev API to &os; so applications that use + libraries like libinput or tslib could be used without any + major changes. Since it is not yet complete, I created a + naive evdev-like API for both kernel and tslib and was able to + run a demo on a Beaglebone Black with 4DCAPE-43T.

Once evdev makes it into the tree, both hardware drivers can be modified to include "report events" @@ -610,59 +618,61 @@

This completed project includes changes to better manage - the vnode freelist and to streamline the allocation and freeing of - vnodes.

+ the vnode freelist and to streamline the allocation and + freeing of vnodes.

Vnode cache recycling was reworked to meet free and unused - vnode targets. Free vnodes are rarely completely free; rather, - they are just ones that are cheap to recycle. Usually they are - for files which have been stat'd but not read; these usually have - inode and namecache data attached to them. The free vnode target - is the preferred minimum size of a sub-cache consisting mostly of - such files. The system balances the size of this sub-cache with - its complement to try to prevent either from thrashing while the - other is relatively inactive. The targets express a preference - for the best balance.

+ vnode targets. Free vnodes are rarely completely free; + rather, they are just ones that are cheap to recycle. Usually + they are for files which have been stat'd but not read; these + usually have inode and namecache data attached to them. The + free vnode target is the preferred minimum size of a sub-cache + consisting mostly of such files. The system balances the size + of this sub-cache with its complement to try to prevent either + from thrashing while the other is relatively inactive. The + targets express a preference for the best balance.

"Above" this target there are 2 further targets (watermarks) related to the recyling of free vnodes. In the - best-operating case, the cache is exactly full, the free list has - size between vlowat and vhiwat above the free target, and - recycling from the free list and normal use maintains this state. - Sometimes the free list is below vlowat or even empty, but this - state is even better for immediate use, provided the cache is not - full. Otherwise, vnlru_proc() runs to reclaim enough vnodes - (usually non-free ones) to reach one of these states. The - watermarks are currently hard-coded as 4% and 9% of the available - space. These, and the default of 25% for wantfreevnodes, are too - large if the memory size is large. For example, 9% of 75% of MAXVNODES - is more than 566000 vnodes to reclaim whenever vnlru_proc() - becomes active.

+ best-operating case, the cache is exactly full, the free list + has size between vlowat and vhiwat above the free target, and + recycling from the free list and normal use maintains this + state. Sometimes the free list is below vlowat or even empty, + but this state is even better for immediate use, provided the + cache is not full. Otherwise, vnlru_proc() runs to + reclaim enough vnodes (usually non-free ones) to reach one of + these states. The watermarks are currently hard-coded as 4% + and 9% of the available space. These, and the default of 25% + for wantfreevnodes, are too large if the memory size is large. + For example, 9% of 75% of MAXVNODES is more than 566000 vnodes + to reclaim whenever vnlru_proc() becomes active.

-

The vfs.vlru_alloc_cache_src sysctl is removed. - New code frees namecache sources as the last chance to satisfy the - highest watermark, instead of selecting source vnodes randomly. - This provides good enough behavior to keep vn_fullpath() working - in most situations. Filesystem layouts with deep trees, where the - removed knob was required, is thus handled automatically.

+

The vfs.vlru_alloc_cache_src sysctl is removed. New + code frees namecache sources as the last chance to satisfy the + highest watermark, instead of selecting source vnodes + randomly. This provides good enough behavior to keep + vn_fullpath() working in most situations. Filesystem + layouts with deep trees, where the removed knob was required, + is thus handled automatically.

As the kernel allocates and frees vnodes, it fully - initializes them on every allocation and fully releases them on - every free. These are not trivial costs: it starts by zeroing a - large structure, then initializes a mutex, a lock manager lock, an - rw lock, four lists, and six pointers. Looking at - vfs.vnodes_created, these operations are being done - millions of times an hour on a busy machine.

+ initializes them on every allocation and fully releases them + on every free. These are not trivial costs: it starts by + zeroing a large structure, then initializes a mutex, a lock + manager lock, an rw lock, four lists, and six pointers. + Looking at vfs.vnodes_created, these operations are + being done millions of times an hour on a busy machine.

As a performance optimization, this code update uses the uma_init and uma_fini routines to do these initializations and - cleanups only as the vnodes enter and leave the vnode zone. With - this change, the initializations are done kern.maxvnodes - times at system startup, and then only rarely again. The frees - are done only if the vnode zone shrinks, which never happens in - practice. For those curious about the avoided work, look at the - vnode_init() and vnode_fini() functions in sys/kern/vfs_subr.c to - see the code that has been removed from the main vnode + cleanups only as the vnodes enter and leave the vnode zone. + With this change, the initializations are done + kern.maxvnodes times at system startup, and then only + rarely again. The frees are done only if the vnode zone + shrinks, which never happens in practice. For those curious + about the avoided work, look at the vnode_init() and + vnode_fini() functions in sys/kern/vfs_subr.c to see + the code that has been removed from the main vnode allocation/free path.

 @@ -682,9 +692,9 @@

The QLogic HBA driver, isp(4), received a - substantial set of changes. The primary goal was to make the Fibre - Channel target role work well with CTL, but many other things were - also fixed/improved:

+ substantial set of changes. The primary goal was to make the + Fibre Channel target role work well with CTL, but many other + things were also fixed/improved:

  • Added support for modern 16Gbps 26xx FC cards.
    • @@ -692,23 +702,26 @@
  • The firmware in ispfw(4) were updated to the latest versions.
    • -
  • Target role support was fixed and tested for all FC cards from - ancient 1Gbps 22xx to modern 16Gbps 26xx.
    • +
  • Target role support was fixed and tested for all FC cards + from ancient 1Gbps 22xx to modern 16Gbps 26xx.
    • -
  • Port database handling was unified for target and initiator - roles, allowing HBA port to play both roles at the same time.
    • +
  • Port database handling was unified for target and + initiator roles, allowing HBA port to play both roles at the + same time.
  • The maximal number of ports was increased from 256 to 1024.
    • -
  • Multi-ID (NPIV) functionality was fixed/implemented, allowing - 24xx and above cards to provide up to 255 virtual FC ports per - physical port.
    • +
  • Multi-ID (NPIV) functionality was fixed/implemented, + allowing 24xx and above cards to provide up to 255 virtual + FC ports per physical port.
    • -
  • Added support for 8-byte LUNs for 24xx and above cards.
    • +
  • Added support for 8-byte LUNs for 24xx and above + cards.
-

The code is committed to &os; head and stable/10 branches.

+

The code is committed to &os; head and stable/10 + branches.

@@ -727,7 +740,8 @@ - Raspberry Pi: VideoCore Userland Application Packaging + Raspberry Pi: VideoCore Userland Application + Packaging @@ -750,15 +764,15 @@

The Raspberry Pi SoC consists of two parts: ARM and GPU (VideoCore). Many interesting features like OpenGL, video - playback, and HDMI controls are implemented on the VideoCore side - and can be accessed from the OS through libraries provided by - Broadcom (userland repo). These libraries were ported to &os; - some time ago, so Mikaël created the port - misc/raspberrypi-userland for them. He also created a - port for omxplayer (a low-level video player that + playback, and HDMI controls are implemented on the VideoCore + side and can be accessed from the OS through libraries + provided by Broadcom (userland repo). These libraries were + ported to &os; some time ago, so Mikaël created the port + misc/raspberrypi-userland for them. He also created + a port for omxplayer (a low-level video player that utilizes VideoCore APIs) and is working on a port for Kodi - (formerly XBMC), a more user-firendly media player software with - Raspberry Pi support.

+ (formerly XBMC), a more user-firendly media player software + with Raspberry Pi support.

 @@ -782,16 +796,16 @@

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

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

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

-

Currently, only the 0.10 branch is functional. See our - wiki page for a complete list of applications.

+

Currently, only the 0.10 branch is functional. See our wiki + page for a complete list of applications.

We also sent updates for some components of LXDE, required for the LXQt desktop:

@@ -802,9 +816,8 @@
  • x11/lxmenu-data 0.1.4
    • -

    Binary packages are available (only for test purposes) - which are regularly tested with the KDE development - repository.

    +

    Binary packages are available (only for test purposes) which + are regularly tested with the KDE development repository.

    @@ -838,14 +851,15 @@

    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.

    + 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 slightly fewer than 300 new ports, in particular:

    @@ -878,7 +892,8 @@     -

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

    +

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

         @@ -949,17 +964,18 @@

    I recently became involved with &os; (as in, the last 2-3 - weeks), and found myself quickly involved with Ports development. - What struck me immediately was the difficulty in providing a Python - package that was depended upon by multiple versions of Python. As - it turns out, poudriere can currently only generate one package - per port, meaning that a Python version-neutral (compatible with - 2.x and 3.x) port cannot simultaneously be packaged for each - variant at the same time.

    + weeks), and found myself quickly involved with Ports + development. What struck me immediately was the difficulty in + providing a Python package that was depended upon by multiple + versions of Python. As it turns out, poudriere can currently + only generate one package per port, meaning that a Python + version-neutral (compatible with 2.x and 3.x) port cannot + simultaneously be packaged for each variant at the same + time.

    I discussed the issue with &a.koobs;, who suggested that I - look into implementing a "variants protocol" within the - Ports framework and the necessary changes to poudriere to + look into implementing a "variants protocol" within + the Ports framework and the necessary changes to poudriere to allow a port to generate more than one package.

    Support for variants is strongly needed in Ports and @@ -967,16 +983,16 @@