From 16c6b370d2029618cd2e7d5bb7cd5e2de1c971be Mon Sep 17 00:00:00 2001 From: Warren Block Date: Fri, 28 Oct 2016 18:59:37 +0000 Subject: [PATCH] Whitespace-only fixes, translators please ignore. --- .../news/status/report-2016-07-2016-09.xml | 1001 +++++++++-------- 1 file changed, 524 insertions(+), 477 deletions(-) diff --git a/en_US.ISO8859-1/htdocs/news/status/report-2016-07-2016-09.xml b/en_US.ISO8859-1/htdocs/news/status/report-2016-07-2016-09.xml index fb0af1ef86..5e2039dc40 100644 --- a/en_US.ISO8859-1/htdocs/news/status/report-2016-07-2016-09.xml +++ b/en_US.ISO8859-1/htdocs/news/status/report-2016-07-2016-09.xml @@ -26,7 +26,7 @@ 2016.

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

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

Thanks to all the reporters for the excellent work!

@@ -110,19 +110,18 @@

Currently, &os; is well proven as a base for routers (pfSense, OPNSense, BSDRP) and NAS (FreeNAS, - zfsGuru, NAS4Free). However, - &os;-based solutions are almost completely absent in the - virtualization area, and ClonOS is one of the - attempts to change that. -

+ zfsGuru, NAS4Free). + However, &os;-based solutions are almost completely absent in + the virtualization area, and ClonOS is one of + the attempts to change that.

-

ClonOS is a new free open-source &os;-based platform for virtual - environment creation and management. In the core platform are: -

+

ClonOS is a new free open-source &os;-based platform for + virtual environment creation and management. In the core + platform are:

-

Currently, the unstable releases work fine with our Gtk3 ports - available in the ports tree, but in the future, support for 3.18 - will be removed in preference of 3.20.x.

+

Currently, the unstable releases work fine with our Gtk3 + ports available in the ports tree, but in the future, support + for 3.18 will be removed in preference of 3.20.x.

@@ -581,24 +587,26 @@ -

This project was started during Google Summer of Code this year. - The aim was to create a library which can convert the audit trail - files in Linux Audit format or the format used by Windows to the BSM - format used by &os; for its audit logs. Apart from that, - I wanted to create a simple command-line tool and extend - auditdistd so that it is possible to send non-BSM logs to - it over a secure connection and save those audit - logs on disk, preferably in the BSM format.

+

This project was started during Google Summer of Code this + year. The aim was to create a library which can convert the + audit trail files in Linux Audit format or the format used by + Windows to the BSM format used by &os; for its audit logs. + Apart from that, I wanted to create a simple command-line tool + and extend auditdistd so that it is possible to send + non-BSM logs to it over a secure connection and save those + audit logs on disk, preferably in the BSM format.

So far, it is possible to reasonably convert some of the most - common Linux audit log events to BSM, but it still needs a lot of - work. Secondly, I was able to configure auditdistd to - communicate with CentOS over an insecure connection. Thirdly, the - command-line tool is usable but not perfect.

+ common Linux audit log events to BSM, but it still needs a lot + of work. Secondly, I was able to configure + auditdistd to communicate with CentOS over an + insecure connection. Thirdly, the command-line tool is usable + but not perfect.

-

The present work focuses on configuring the secure TLS connection - between CentOS and auditdistd. I have already tried using - rsyslogd but was not able to make it work.

+

The present work focuses on configuring the secure TLS + connection between CentOS and auditdistd. I have + already tried using rsyslogd but was not able to make it + work.

@@ -606,17 +614,18 @@ - I need more examples of rare Linux Audit logs; please send me - some examples if you have any. It is much easier to improve the - conversion process with real-life examples of the audit events you - try to convert. + I need more examples of rare Linux Audit logs; please send + me some examples if you have any. It is much easier to + improve the conversion process with real-life examples of the + audit events you try to convert. - Configure auditdistd to be able to communicate with some - software on CentOS over TLS in order to receive audit logs. I - was not able to come up with a simple solution for that. + Configure auditdistd to be able to communicate + with some software on CentOS over TLS in order to receive + audit logs. I was not able to come up with a simple solution + for that. - Additional open tasks are listed on the Wiki page and in the - TODO file in the root directory of the project. + Additional open tasks are listed on the Wiki page and in + the TODO file in the root directory of the project. @@ -634,33 +643,34 @@ -

Non-Transparent Bridges allow creation of memory windows between - different systems using the regular PCIe links of CPUs as a - transport. During the last quarter, the NTB subsystem gained a - significant set of improvements and fixes:

+

Non-Transparent Bridges allow creation of memory windows + between different systems using the regular PCIe links of CPUs + as a transport. During the last quarter, the NTB subsystem + gained a significant set of improvements and fixes:

-

The code is committed to the &os; head, stable/11 and stable/10 - branches.

+

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

@@ -674,7 +684,8 @@ Support for I/OAT and other DMA offloads. - Creating a more efficient packet transport protocol. + Creating a more efficient packet transport + protocol. Creating a greater variety of NTB applications. @@ -703,19 +714,21 @@

The ZFS code base in &os; regularly gets merges of new code, - staying in sync with latest OpenZFS/Illumos sources. Among other - things, the latest merge included the following improvements:

+ staying in sync with latest OpenZFS/Illumos sources. Among + other things, the latest merge included the following + improvements:

Along with support for new boards (SolidRun ClearFog and @@ -820,15 +834,16 @@ -

The Elastic Network Adapter (ENA) is a 25G SmartNIC developed by - Annapurna Labs based on a custom ARMv8 chip. This is a - high-performance networking card that is available to AWS virtual - machines. It introduces enhancements in network utilization - scalability on EC2 machines running various operating systems, in - particular &os;.

+

The Elastic Network Adapter (ENA) is a 25G SmartNIC developed + by Annapurna Labs based on a custom ARMv8 chip. This is a + high-performance networking card that is available to AWS + virtual machines. It introduces enhancements in network + utilization scalability on EC2 machines running various + operating systems, in particular &os;.

-

The goal of &os; enablement is to provide top performance and a - wide range of monitoring and management features such as:

+

The goal of &os; enablement is to provide top performance and + a wide range of monitoring and management features such + as:

The current state offers stable driver operation with good - performance on machines running &os; directly on the hardware.

+ performance on machines running &os; directly on the + hardware.

@@ -893,16 +909,18 @@

Alpine is a family of Platform-on-Chip devices, including - multi-core 32-bit (first-gen Alpine) and 64-bit (Alpine V2) ARM - CPUs, developed by Annapurna Labs.

+ multi-core 32-bit (first-gen Alpine) and 64-bit (Alpine V2) + ARM CPUs, developed by Annapurna Labs.

The primary focus areas of the Alpine platform are - high-performance networking, storage and embedded applications. The - network subsystem features 10-, 25-, and 50-Gbit Ethernet - controllers with support for virtualization, load-balancing, - hardware offload and other advanced features.

+ high-performance networking, storage and embedded + applications. The network subsystem features 10-, 25-, and + 50-Gbit Ethernet controllers with support for virtualization, + load-balancing, hardware offload and other advanced + features.

-

A basic patch set has already been committed to HEAD including:

+

A basic patch set has already been committed to HEAD + including:

+

Additional work, such as an MSI-X driver and full Ethernet - support, is currently undergoing community review on Phabricator.

+ support, is currently undergoing community review on + Phabricator.

-

The multi-user SMP system is stable and fully working, along with - the 1G and 10G Ethernet links.

+

The multi-user SMP system is stable and fully working, along + with the 1G and 10G Ethernet links.

-

The interrupt management code has been adjusted to work with the - new INTRNG framework on both ARM32 and ARM64.

+

The interrupt management code has been adjusted to work with + the new INTRNG framework on both ARM32 and ARM64.

@@ -936,7 +955,8 @@ - Documenting the History of Utilities in /bin and /sbin + Documenting the History of Utilities in /bin and + /sbin @@ -957,23 +977,25 @@

For EuroBSDcon, I began looking into inconsistencies within - components inside our family of operating systems. My workflow - consisted of reading the documentation for a given utility and - checking the history in the revision control system for missing - fixes or functionality in the trees of NetBSD, &os;, OpenBSD, and - DragonFly BSD.

+ components inside our family of operating systems. My + workflow consisted of reading the documentation for a given + utility and checking the history in the revision control + system for missing fixes or functionality in the trees of + NetBSD, &os;, OpenBSD, and DragonFly BSD.

One thing which became obvious very quickly was the - inconsistency between operating systems about where and/or which - version a utility originated in, despite our common heritage.

+ inconsistency between operating systems about where and/or + which version a utility originated in, despite our common + heritage.

-

I began with working through the man pages in &os;, verifying the - details in pages which already had a history section and making - patches for those which did not.

+

I began with working through the man pages in &os;, verifying + the details in pages which already had a history section and + making patches for those which did not.

-

From there, changes were propogated out to NetBSD, OpenBSD, and - Dragonfly BSD where applicable (not all utilities originated from - the same source or implementation, for example).

+

From there, changes were propogated out to NetBSD, OpenBSD, + and Dragonfly BSD where applicable (not all utilities + originated from the same source or implementation, for + example).

This was a good exercise in:

@@ -981,28 +1003,29 @@
  • Becoming familiar with mandoc.
    • -
  • Using tools such as the linting functionality in mandoc and - the igor documentation script.
    • +
  • Using tools such as the linting functionality in mandoc + and the igor documentation script.
  • Becoming familiar with the locations where things are - documented and with external sources of historical information, - such as the BSD Family Tree included in the &os; base - system, and projects like The UNIX - Heritage Society and the manual - library on cat-v.org which - hosts copies of manuals such as those shipped with - Research - UNIX. These manuals are not commonly available - elsewhere.
    • + documented and with external sources of historical + information, such as the BSD Family Tree included in the + &os; base system, and projects like + The UNIX Heritage Society + and the manual library + on cat-v.org which hosts + copies of manuals such as those shipped with + Research UNIX. + These manuals are not commonly available elsewhere. - Cover the remaining manuals for userland utilities, and maybe - expand into library and syscall APIs, though I say that without - estimating the feasibility. The history of components originating from a - closed-source operating system is tricky to document, - since older versions are not always available. + Cover the remaining manuals for userland utilities, and + maybe expand into library and syscall APIs, though I say that + without estimating the feasibility. The history of components + originating from a closed-source operating system is tricky to + document, since older versions are not always + available.     @@ -1032,22 +1055,23 @@ -

    &os; provides an API for guest operating systems to access shared folders on - the host so that the kernel driver can expose them to the - guest's userland. This project aims to add such functionality to - the VirtualBox Guest Additions driver.

    +

    &os; provides an API for guest operating systems to access + shared folders on the host so that the kernel driver can + expose them to the guest's userland. This project aims to add + such functionality to the VirtualBox Guest Additions + driver.

    Good progress was made over last few months. Developers were able to mount a filesystem in read-only mode and, with some - limitations, in read-write mode. The implementation still lacks - some critical pieces, but the roadmap is clear.

    + limitations, in read-write mode. The implementation still + lacks some critical pieces, but the roadmap is clear.

    Finish the missing pieces. - + Implement proper locking. - + General clean-up and bugfixes. @@ -1079,31 +1103,32 @@ -

    evdev is a portable, API-compatible implementation of - the Linux /dev/input/eventX interface. It covers a wide - variety of input devices like keyboards, mice, and touchscreens - (with multitouch support), and support for it is implemented in a - lot of existing userland components like Qt, libinput, and - tslib.

    +

    evdev is a portable, API-compatible implementation + of the Linux /dev/input/eventX interface. It covers + a wide variety of input devices like keyboards, mice, and + touchscreens (with multitouch support), and support for it is + implemented in a lot of existing userland components like Qt, + libinput, and tslib.

    -

    evdev support was started by Jakub Klama as a Google SoC - 2014 project, and later picked up and finished by Vladimir +

    evdev support was started by Jakub Klama as a Google + SoC 2014 project, and later picked up and finished by Vladimir Kondratiev. General API and evdev support bits for - ukbd and ums were committed to HEAD. Support was - also added for TI's AM33xx touchstreen controller (the popular - BeagleBone is based on the AM33xx) and the official touschreen for - the Raspberry Pi. Multitouch support for the Raspberry Pi was - successfully demonstarted using the latest Qt development branch.

    - + ukbd and ums were committed to HEAD. + Support was also added for TI's AM33xx touchstreen controller + (the popular BeagleBone is based on the AM33xx) and the + official touschreen for the Raspberry Pi. Multitouch support + for the Raspberry Pi was successfully demonstarted using the + latest Qt development branch.

    + - Documentation. In particular, manual pages are needed for the - KPI. + Documentation. In particular, manual pages are needed for + the KPI. Support additional hardware. - Enable evdev support in existing ports, and add new - evdev-dependent ports. + Enable evdev support in existing ports, and add + new evdev-dependent ports. @@ -1135,33 +1160,33 @@

    Transparent superpage support has been added. This allows - &os; to create 2MiB blocks with a single pagetable and TLB entry. - This shows a small but significant improvement in the + &os; to create 2MiB blocks with a single pagetable and TLB + entry. This shows a small but significant improvement in the buildworld time on ThunderX machines. Superpages have been - enabled in head and merged to stable/11, but they are - disabled by default on stable/11 due to a lack of testing - there.

    + enabled in head and merged to stable/11, but they are disabled + by default on stable/11 due to a lack of testing there.

    Support for the pre-INTRNG interrupt framework has been removed. This means that arm64 requires INTRNG to even build. - This has allowed various cleanups within the arm64 drivers that - interact with the interrupt controller.

    + This has allowed various cleanups within the arm64 drivers + that interact with the interrupt controller.

    -

    The cortex Strings library from Linaro has been imported. The - parts of this that have been shown to be improvements over the - previous C code were attached to the libc build.

    +

    The cortex Strings library from Linaro has been imported. + The parts of this that have been shown to be improvements over + the previous C code were attached to the libc build.

    There is ongoing work to add ACPI support to the kernel. On - ThunderX, &os; can get to the mountroot prompt, however, due to - incomplete ACPI tables the external PCIe support needed to support - the netboot setup in the test cluster is not functional.

    + ThunderX, &os; can get to the mountroot prompt, however, due + to incomplete ACPI tables the external PCIe support needed to + support the netboot setup in the test cluster is not + functional.

    Pine64 support has been committed to head. &os; can now boot - to multiuser with SMP enabled. This includes support for clocks, - the secure ID controller, USB Host controller, GPIOs, non-maskable - interrupts, the AXP81x power management unit, cpu freqency and - voltage scaling, MMC, UART, gigabit networking, the watchdog, and - the thermal sensors.

    + to multiuser with SMP enabled. This includes support for + clocks, the secure ID controller, USB Host controller, GPIOs, + non-maskable interrupts, the AXP81x power management unit, cpu + freqency and voltage scaling, MMC, UART, gigabit networking, + the watchdog, and the thermal sensors.

    @@ -1193,9 +1218,9 @@ -

    The KDE on &os; team focuses on packaging the KDE software and - making sure that the experience of KDE and Qt on &os; is as good as - possible.

    +

    The KDE on &os; team focuses on packaging the KDE software + and making sure that the experience of KDE and Qt on &os; is + as good as possible.

    The following big updates were landed in the ports tree this quarter:

    @@ -1212,15 +1237,16 @@
  • CMake was updated to versions 3.6.1 and 3.6.2.
    • -
  • An important fix was made to qmake, where the clang - version was not correctly detected.
    • +
  • An important fix was made to qmake, where the + clang version was not correctly detected.
  • Qt 5.6.1 was committed to ports.
    • -
  • Phonon and its backend to were updated to 4.9.0 in preparation - for Qt 5.6.1.
    • +
  • Phonon and its backend to were updated to 4.9.0 in + preparation for Qt 5.6.1.
    • -
  • Updated the net-im/telepathy-qt4 port to 0.9.7.
    • +
  • Updated the net-im/telepathy-qt4 port to + 0.9.7.
  • Various LibreSSL related fixes by Matthew Rezny.
    • @@ -1234,9 +1260,10 @@ work:

      -
    • The plasma5 branch has been kept up to date with KDE's upstream and - contains ports for Frameworks 5.26.0, Plasma Desktop 5.8.0, and - Applications 16.08.1 (branches/plasma5).
      • +
    • The plasma5 branch has been kept up to date with KDE's + upstream and contains ports for Frameworks 5.26.0, Plasma + Desktop 5.8.0, and Applications 16.08.1 + (branches/plasma5).
    @@ -1255,106 +1282,110 @@

    The third quarter started with the handover to the ninth Core team as it took office. With four members returning from the - previous core (Baptiste Daroussin, Ed Maste, George Neville-Neil - and Hiroki Sato), one returning member after a term away (John - Baldwin), and four members new to core (Allan Jude, Kris Moore, - Benedict Reuschling and Benno Rice), the new core team represents - just about the ideal balance between experience and fresh - blood.

    + previous core (Baptiste Daroussin, Ed Maste, George + Neville-Neil and Hiroki Sato), one returning member after a + term away (John Baldwin), and four members new to core (Allan + Jude, Kris Moore, Benedict Reuschling and Benno Rice), the new + core team represents just about the ideal balance between + experience and fresh blood.

    Beyond handing over all of the ongoing business, reviewing everything on Core's agenda, and other routine changeover - activities, the first action of the new core was to respond to a - query from Craig Rodrigues concerning how hardware supplied to the - project through donations to the &os; Foundation was being - used.

    + activities, the first action of the new core was to respond to + a query from Craig Rodrigues concerning how hardware supplied + to the project through donations to the &os; Foundation was + being used.

    The Foundation does keep records of what hardware has been - supplied over time and has some idea of the original purpose that - hardware was provisioned for, but does not track the current usage - of the project's hardware assets. Cluster administration keeps - their own configuration database, but this is not suitable for - general publication and covers much more than Foundation supplied - equipment. After some discussion it was decided that updated - information about the current disposition of Foundation supplied - equipment should be incorporated in the Foundation's annual - report.

    + supplied over time and has some idea of the original purpose + that hardware was provisioned for, but does not track the + current usage of the project's hardware assets. Cluster + administration keeps their own configuration database, but + this is not suitable for general publication and covers much + more than Foundation supplied equipment. After some + discussion it was decided that updated information about the + current disposition of Foundation supplied equipment should be + incorporated in the Foundation's annual report.

    -

    Ensuring that all of the &os; code base is supplied under open - and unencumbered licensing terms and that we do not infringe on - patent terms or otherwise act counter to any legal requirements - are some of Core's primary concerns. During this quarter, there - were three items of this nature.

    +

    Ensuring that all of the &os; code base is supplied under + open and unencumbered licensing terms and that we do not + infringe on patent terms or otherwise act counter to any legal + requirements are some of Core's primary concerns. During this + quarter, there were three items of this nature.

    • Importing Concurrency Kit. In consultation with the - Foundation's legal counsel, it was determined that the relevant - patents on the 'Read Copy Update' synchronization mechanisms - have expired, and consequently the import of selected parts of - concurrency kit was approved.
      • + Foundation's legal counsel, it was determined that the + relevant patents on the 'Read Copy Update' synchronization + mechanisms have expired, and consequently the import of + selected parts of concurrency kit was approved.
    • The proposal to create a shadow GPLv3 toolchain repository - was put to the community. Ultimately the whole idea has been - rendered largely redundant by faster than anticipated progress - at integrating the latest LLVM toolchain on most of the - interesting system architectures. The goal of a GPL-free base - system is within our grasp.
      • + was put to the community. Ultimately the whole idea has + been rendered largely redundant by faster than anticipated + progress at integrating the latest LLVM toolchain on most of + the interesting system architectures. The goal of a + GPL-free base system is within our grasp. -
    • Reports that GPL code has been pasted into linuxkpi sources - are under investigation. Core would like to stress that great - care must be taken to avoid inadvertent license infringement, - especially when implementing hardware interfaces or similar - where there is limited scope to invent new constants or - otherwise make it clear this is a novel implementation.
      • +
    • Reports that GPL code has been pasted into linuxkpi + sources are under investigation. Core would like to stress + that great care must be taken to avoid inadvertent license + infringement, especially when implementing hardware + interfaces or similar where there is limited scope to invent + new constants or otherwise make it clear this is a novel + implementation.

    Work on LLVM has thrown up problems with the presence of - certain pre-compiled binary-only drivers as part of the GENERIC - kernel. Core has adopted the policy that such binary-only code - should be moved to loadable modules and that the GENERIC kernel - must be compiled entirely from original sources.

    + certain pre-compiled binary-only drivers as part of the + GENERIC kernel. Core has adopted the policy that such + binary-only code should be moved to loadable modules and that + the GENERIC kernel must be compiled entirely from original + sources.

    The item that has absorbed the largest portion of Core's - attention this quarter concerns the project's handling of security - vulnerabilities in bspatch(1), libarchive(3), FreeBSD-update(8) - and portsnap(8). A partial fix was applied in - &os;-SA-16:25.bspatch but this lacks fixes to libarchive code - that were not yet available from upstream.

    + attention this quarter concerns the project's handling of + security vulnerabilities in bspatch(1), libarchive(3), + FreeBSD-update(8) and portsnap(8). A partial fix was applied + in &os;-SA-16:25.bspatch but this lacks fixes to libarchive + code that were not yet available from upstream.

    SecTeam receives privileged early reports of many vulnerabilities and consequently has a strict policy of not commenting publicly until an advisory and patches have been - published. Early access to information about vulnerabilities is - contingent on their ability to avoid premature disclosure, and - without such, they could not have security advisories and + published. Early access to information about vulnerabilities + is contingent on their ability to avoid premature disclosure, + and without such, they could not have security advisories and patches ready to go immediately when the vulnerability is published.

    -

    However, in this case, vulnerabilities were already public and - the lack of any official response from the &os; project was - leading to concern amongst users and some critical press coverage. - Core stepped in and published a statement clarifying the situation - and the particular difficulties involved in securely modifying the - mechanisms used to deliver security patches. Core believes that - prompt notification and discussion of the implications and - possible workarounds to any public vulnerability should not wait - on the availability of formal OS patches.

    +

    However, in this case, vulnerabilities were already public + and the lack of any official response from the &os; project + was leading to concern amongst users and some critical press + coverage. Core stepped in and published a statement + clarifying the situation and the particular difficulties + involved in securely modifying the mechanisms used to deliver + security patches. Core believes that prompt notification and + discussion of the implications and possible workarounds to any + public vulnerability should not wait on the + availability of formal OS patches.

    -

    The OpenSSH project has deprecated DSA keys upstream. &os; had - kept DSA keys enabled in the later 10.x releases for compatibility - reasons, but with the release of 11.0 the time has come to - synchronize again with upstream. Since there are numerous DSA - keys in use in the &os; cluster, this necessitated an - exercise to get replacement keys installed. Core would like to - thank David Wolfskill and the accounts team for handling the surge - in key changes with a great deal of aplomb.

    +

    The OpenSSH project has deprecated DSA keys upstream. &os; + had kept DSA keys enabled in the later 10.x releases for + compatibility reasons, but with the release of 11.0 the time + has come to synchronize again with upstream. Since there are + numerous DSA keys in use in the &os; cluster, this + necessitated an exercise to get replacement keys installed. + Core would like to thank David Wolfskill and the accounts team + for handling the surge in key changes with a great deal of + aplomb.

    During this quarter we welcomed Michael Zhilin, Imre Vadasz, - Steve Kiernan and Toomas Soome as new source committers. Over the - same period, we said farewell to Martin Wilke and Erwin Lansing - who have handed in their commit bits. We wish them well in their - future endeavours and hope to see them return as soon as they - can.

    + Steve Kiernan and Toomas Soome as new source committers. Over + the same period, we said farewell to Martin Wilke and Erwin + Lansing who have handed in their commit bits. We wish them + well in their future endeavours and hope to see them return as + soon as they can.

    @@ -1373,46 +1404,49 @@

    Work was done to properly lock the time-keeping code. The - existing code correctly interoperated with readers, both kernel- - and user-space, giving them lock-less access to the actual data - ('timehands') needed to derive the time of day from the - timecounter hardware in the presence of updaters. But updates - of the timehands, which are performed by periodic clock - interrupts, the ntpd-driven sys_ntp_adjtime(2) syscall, the - settimeofday(2) syscall, pps sync, and possibly other sources, - were not coordinated. Moreso, the NTP code was locked by Giant, - which did not really serve any purpose.

    - -

    As a result of the work, locking was applied to ensure that any - timehands adjustments are performed by a single mutator. An - interesting case is the parallel modification of the timehands - from the top of the kernel, for instance the settimeoday(2) - syscall, and a simultaneous clock tick event, where the syscall - has already acquired the resources. In this case, it is highly - desirable to not block (spin) in the tick handler, and the - required adjustments are performed by the already executing call - from the top half. There, the typical trylock operation is desired, - which was surprisingly lacking in our spinlock implementation. - mtx_trylock_spin(9) was implemented and is used for this + existing code correctly interoperated with readers, both + kernel- and user-space, giving them lock-less access to the + actual data ('timehands') needed to derive the time of day + from the timecounter hardware in the presence of updaters. + But updates of the timehands, which are performed by periodic + clock interrupts, the ntpd-driven sys_ntp_adjtime(2) + syscall, the settimeofday(2) syscall, pps sync, and + possibly other sources, were not coordinated. Moreso, the NTP + code was locked by Giant, which did not really serve any purpose.

    -

    The userspace getttimeofday(2) implementation was enhanced to - allow syscall-less operation on machines that use HPET hardwire - for timecounters. The HPET algorithm coexists with older - RDTSC-based code, allowing dynamic switching of timecounters. - HPET registers a page that is mmap(2)-ed readonly by libc into - userland application programs' address space as needed. - Measurements demonstrated modest improvements in gettimeofday(2) - performance, but, not unexpectedly, even the syscall-less HPET - timecounter is slower than invoking a syscall for RDTSC.

    +

    As a result of the work, locking was applied to ensure that + any timehands adjustments are performed by a single mutator. + An interesting case is the parallel modification of the + timehands from the top of the kernel, for instance the + settimeoday(2) syscall, and a simultaneous clock tick + event, where the syscall has already acquired the resources. + In this case, it is highly desirable to not block (spin) in + the tick handler, and the required adjustments are performed + by the already executing call from the top half. There, the + typical trylock operation is desired, which was surprisingly + lacking in our spinlock implementation. + mtx_trylock_spin(9) was implemented and is used for + this purpose.

    + +

    The userspace getttimeofday(2) implementation was + enhanced to allow syscall-less operation on machines that use + HPET hardwire for timecounters. The HPET algorithm coexists + with older RDTSC-based code, allowing dynamic switching of + timecounters. HPET registers a page that is + mmap(2)-ed readonly by libc into userland application + programs' address space as needed. Measurements demonstrated + modest improvements in gettimeofday(2) performance, + but, not unexpectedly, even the syscall-less HPET timecounter + is slower than invoking a syscall for RDTSC.

    Some not strictly interwined but related code is the time-bound sleep implementation. Handling of races between callouts and the top-half code that sets and processes the timeouts depended on the many fine details of the - callout_stop(9) KPI (kernel programming interface). In - particular, races or unpunctual KPI changes usually result in - the "catch-all" unkillable thread state with the + callout_stop(9) KPI (kernel programming interface). + In particular, races or unpunctual KPI changes usually result + in the "catch-all" unkillable thread state with the "-" waitchain bug. The sleepqueue timeout code was rewritten to stop depending on the KPI details, which removed the source of recurring bugs, and also surprisingly simplified @@ -1439,26 +1473,27 @@

    UEFI (Unified Extensible Firmware Interface) specifies two - kinds of services for use by operating systems. Boot Services are - designed for OS loaders to load and initialize kernels, - while Runtime Services are meant to be used by kernels - during regular system operations. The boot and runtime phases are + kinds of services for use by operating systems. Boot Services + are designed for OS loaders to load and initialize kernels, + while Runtime Services are meant to be used by kernels during + regular system operations. The boot and runtime phases are explicitly separated. During boot, when loaders are executed, - the machine configuration is owned by UEFI. During runtime, the - kernel manages the configuration, but needs to inform the firmware - about any changes that are made.

    + the machine configuration is owned by UEFI. During runtime, + the kernel manages the configuration, but needs to inform the + firmware about any changes that are made.

    -

    The model of split boot/runtime configuration makes assumptions - about the OS architecture that do not quite apply to the existing - &os; codebase. For instance, the firmware notification of the - future runtime configuration must be done while the loader is - effectively still in control. In technical terms, the - SetVirtualAddressMap() call must be made with the 1:1 - physical:virtual mapping on amd64 systems, which for &os; means - that the call can be only issued by the loader. But the loader - needs to know intimate details of the kernel address map to - provide the requested information. This creates a new, - unfortunate, coupling between loader and kernel.

    +

    The model of split boot/runtime configuration makes + assumptions about the OS architecture that do not quite apply + to the existing &os; codebase. For instance, the firmware + notification of the future runtime configuration must be done + while the loader is effectively still in control. In + technical terms, the SetVirtualAddressMap() call must + be made with the 1:1 physical:virtual mapping on amd64 + systems, which for &os; means that the call can be only issued + by the loader. But the loader needs to know intimate details + of the kernel address map to provide the requested + information. This creates a new, unfortunate, coupling + between loader and kernel.

    Reading the publicly available information about the MS Windows boot process explained the UEFI control transfer @@ -1474,50 +1509,52 @@ centered around utilizing the direct address map (DMAP) on amd64, which currently always exists and linearly maps at least the lower 4G of physical addresses at some KVA location. - It was supposed that the kernel would export the DMAP details like - linear base and guaranteed size for loader from its ELF image, - and provide the needed overflow map if the DMAP cannot + It was supposed that the kernel would export the DMAP details + like linear base and guaranteed size for loader from its ELF + image, and provide the needed overflow map if the DMAP cannot completely serve. Unfortunately, two show-stopper bugs were discovered with this approach.

    First, EDK-based firmware apparently requires that the runtime mapping exists simultaneously with the physical - mapping for the SetVirtualAddressMap() call. Second, there - were references from other open-source projects mentioning - that some firmware required the presence of the physical - mapping during the runtime call. Effectively, this forces both - kernel and loader to provide both mappings for all runtime - calls.

    + mapping for the SetVirtualAddressMap() call. Second, + there were references from other open-source projects + mentioning that some firmware required the presence of the + physical mapping during the runtime call. Effectively, this + forces both kernel and loader to provide both mappings for all + runtime calls.

    With such restrictions, informing the firmware about the details of the kernel address space only adds useless work. We could just as easily establish the 1:1 physical mapping - during runtime and get rid of SetVirtualAddressMap() entirely. - This approach was coded and the kernel interface to access - runtime services is based on it.

    + during runtime and get rid of + SetVirtualAddressMap() entirely. This approach was + coded and the kernel interface to access runtime services is + based on it.

    During the development, particularly when trying to make the loader modifications, it was quickly realized that there - were no fault-reporting facilities in loader.efi. Machine - exceptions resulted in a silent hang. Curiosly, in such a - situation the Intel firmware outputs the error code over the - serial port on 115200/8/1 settings, regardless of UEFI console - configuration, which was discovered by accident. + were no fault-reporting facilities in loader.efi. + Machine exceptions resulted in a silent hang. Curiosly, in + such a situation the Intel firmware outputs the error code + over the serial port on 115200/8/1 settings, regardless of + UEFI console configuration, which was discovered by accident. Unfortunately, the error code alone is not enough to diagnose most problems.

    -

    A primitive fault reporter was written for loader.efi on - amd64, which intercepts exceptions from the firmware IDT and - dumps the machine state to the loader console. Due to the - complexity of the interception and possible bugs which might - do more harm than good there, the dumper is only activated with - explicit administrator action.

    +

    A primitive fault reporter was written for + loader.efi on amd64, which intercepts exceptions from + the firmware IDT and dumps the machine state to the loader + console. Due to the complexity of the interception and + possible bugs which might do more harm than good there, the + dumper is only activated with explicit administrator + action.

    Note that the described work only provides the kernel interfaces to make calling the EFI runtime services as easy as calling a regular C function. User-visible feature development making use of the new interfaces is being - performed right now.

    + performed right now.

    @@ -1547,8 +1584,8 @@

    The &os; Release Engineering Team continued the 11.0-RELEASE cycle which was planned to be released in September, but as a - result of several last-minute issues, - the final release announcement was delayed.

    + result of several last-minute issues, the final release + announcement was delayed.

    @@ -1614,9 +1651,9 @@

    DRM from Linux 4.8 was ported to the drm-next branch. This branch should be used for radeon and - amdgpu cards. The drm-next-4.7 branch should be used - for i915 cards due to instabilities in - the intel driver in drm-next branch.

    + amdgpu cards. The drm-next-4.7 branch + should be used for i915 cards due to instabilities + in the intel driver in drm-next branch.

    Johannes Lundberg has been working on getting the Wayland environment running on &os;. The Wayland ports are in @@ -1664,8 +1701,8 @@ 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.

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

    @@ -1676,8 +1713,8 @@ budget for 2016 is $1,250,000 and we have raised $271,500 so far. Our Q1-Q3 financial reports will be posted in early November. As you can see, we need your donations to - continue supporting &os; at our current level. Please consider - making a donation at https://www.FreeBSDfoundation.org/donate/.

    OS Improvements

    @@ -1687,24 +1724,26 @@ our internal software developer staff members. Two Foundation-funded projects continued last quarter: one project is to port NetBSD's blacklistd daemon and related - elements to &os;, and the second is phase two of the &os;/arm64 - port.

    + elements to &os;, and the second is phase two of the + &os;/arm64 port.

    Foundation staff members were responsible for many changes over the quarter. Kostik Belousov accomplished this work last quarter:

      -
    • Provided kernel support for EFI Runtime Services calls.
      • +
    • Provided kernel support for EFI Runtime Services + calls.
      • -
    • Implemented getttimeofday(2) purely in userspace for HPET - timers
      • +
    • Implemented getttimeofday(2) purely in userspace + for HPET timers
    • Implemented fdatasync(2)
    • Improved the locking of the time keeping code
      • -
    • Made the sleepqueue code immune to rapid callout changes
      • +
    • Made the sleepqueue code immune to rapid callout + changes
    • Made many stability fixes, the most important of which were UFS issues and an i386 bug
      • @@ -1723,10 +1762,11 @@ and prepare LLD as the replacement linker in the &os; base system -
    • Switched to using LLVM's libunwind in the base system
      • +
    • Switched to using LLVM's libunwind in the base + system
      • -
    • Improved the reproducibility of builds in the &os; base system - and ports
      • +
    • Improved the reproducibility of builds in the &os; base + system and ports
    • Reviewed the blacklistd work that is in progress
      • @@ -1734,11 +1774,11 @@
    • Attended BSDCam 2016, with a primary focus on toolchain discussions
      • -
    • Participated in ongoing Capsicum calls, and helped with the - Capsicumization of several base system utilities
      • +
    • Participated in ongoing Capsicum calls, and helped with + the Capsicumization of several base system utilities
      • -
    • Fixed a number of ELF Tool Chain issues, and integrated a new - upstream version into the &os; base system
      • +
    • Fixed a number of ELF Tool Chain issues, and integrated a + new upstream version into the &os; base system
    • Hosted biweekly graphics calls to coordinate work in progress by funded and volunteer developers
      • @@ -1757,27 +1797,28 @@

      Release Engineering

      Foundation staff member Glen Barber worked with the Release - Engineering team to continue finalizing the 11.0-RELEASE cycle, - which was delayed to address several last-minute issues.

      + Engineering team to continue finalizing the 11.0-RELEASE + cycle, which was delayed to address several last-minute + issues.

      As part of the Cluster Administration team, Glen worked with - the amazing on-site staff at NYI to rack and install two Cavium - ThunderX machines, one of which is used for native package - builds for the &os;/aarch64 architecture, and the other of which - is targeted to be used as a reference machine in the &os; - infrastructure.

      + the amazing on-site staff at NYI to rack and install two + Cavium ThunderX machines, one of which is used for native + package builds for the &os;/aarch64 architecture, and the + other of which is targeted to be used as a reference machine + in the &os; infrastructure.

      Getting Started with &os; Project

      We hired a summer intern, with no experience on &os;, Linux, or any command-line operating system, to figure out on his own how to install and use &os;. He wrote easy-to-follow how-to - guides to help make the new-user experience straightforward and - positive. He submitted bug reports and reported issues through - the appropriate channels, and worked with Glen Barber and Brad - Davis to improve the new user information on FreeBSD.org to make - it easier for new people to get started with &os;. You can find - his how-to guides at https://www.FreeBSDfoundation.org/FreeBSD/how-to-guides/ and check out his interview on BSDNow at http://www.bsdnow.tv/episodes/2016_08_24-the_fresh_bsd_experience.

      @@ -1793,12 +1834,12 @@

      &os; Advocacy and Education

      A large part of our efforts are dedicated to advocating for - the Project. This includes promoting work being done by others - using &os;, producing advocacy literature to teach people about - &os; and ease the path to starting out with &os;, contributing - to the Project, and attending and getting other &os; - contributors to volunteer to run &os; events, staff &os; tables, - and give &os; presentations.

      + the Project. This includes promoting work being done by + others using &os;, producing advocacy literature to teach + people about &os; and ease the path to starting out with &os;, + contributing to the Project, and attending and getting other + &os; contributors to volunteer to run &os; events, staff &os; + tables, and give &os; presentations.

      We created new handouts to promote TeachBSD.org (https://www.FreeBSDfoundation.org/wp-content/uploads/2016/08/TeachBSD_half_final.pdf) @@ -1809,27 +1850,29 @@ href="https://www.FreeBSDfoundation.org/past-issues/FreeBSD-and-rtems/">https://www.FreeBSDfoundation.org/past-issues/FreeBSD-and-rtems/.

      We also published monthly newsletters to highlight work being - done to support &os;, tell you about upcoming events, and other - information to keep you in the loop of what we’re doing to - support the &os; Project and community https://www.FreeBSDfoundation.org/news-and-events/newsletter/.

      Conferences and Events

      The FreeBSD Foundation sponsors many conferences, events, and - summits around the globe. These events can be BSD-related, open - source, or technology events geared towards underrepresented - groups.

      + summits around the globe. These events can be BSD-related, + open source, or technology events geared towards + underrepresented groups.

      We support the &os;-focused events to help provide a venue for sharing knowledge, to work together on projects, and facilitate collaboration between developers and commercial - users. This all helps provide a healthy ecosystem. We support - the non-&os; events to promote and raise awareness about &os;, - to increase the use of &os; in different applications, and to - recruit more contributors to the Project.

      + users. This all helps provide a healthy ecosystem. We + support the non-&os; events to promote and raise awareness + about &os;, to increase the use of &os; in different + applications, and to recruit more contributors to the + Project.

      -

      This quarter, we sponsored and/or attended the following events:

      +

      This quarter, we sponsored and/or attended the following + events:

      • Texas Linux Fest, July 8-9, 2016, Austin, TX @@ -1862,11 +1905,13 @@
        • Held a Women in Tech BoF in partnership with ACM-W Europe
          • +
        • Bennedict organized the EuroBSDCon Developer Summit
        • Deb gave a Foundation Update talk and Hiroki Sato and - Benedict Reuschling joined her for a Q&A session.
          • + Benedict Reuschling joined her for a Q&A + session.
        • Kirk McKusick taught his two-day &os; tutorial (https://2016.eurobsdcon.org/speakers/#kirkmckusick)
          • @@ -1894,13 +1939,14 @@
        -

        We sponsored three &os; contributors to attend EuroBSDCon.

        +

        We sponsored three &os; contributors to attend + EuroBSDCon.

        Legal/&os; IP

        The Foundation owns the &os; trademarks, and it is our - responsibility to protect them. We continued to review requests - and grant permission to use the trademarks.

        + responsibility to protect them. We continued to review + requests and grant permission to use the trademarks.

        &os; Community Engagement

        @@ -1911,7 +1957,8 @@

        Other Stuff We Did

        We welcomed Kylie Liang and Philip Paeps to the Board of - Directors. More information and interviews can be found at: https://www.FreeBSDfoundation.org/blog/FreeBSD-foundation-welcomes-new-board-members/.

        George attended the ARM Partner Meeting in Cambridge.

        @@ -1969,9 +2016,9 @@

        Several developers have undertaken a recent effort to - sandbox additional applications in the base system. - This work is proceeding nicely and one of the goals is to target - basic utilities used in security sensitive applications, like + sandbox additional applications in the base system. This work + is proceeding nicely and one of the goals is to target basic + utilities used in security sensitive applications, like freebsd-update and portsnap.

        This work higlighted two longstanding challenges in @@ -2096,7 +2143,7 @@ It is a high-performance linker that supports the ELF, COFF, and Mach-O object formats. Where possible, lld maintains command-line and functional compatibility with the - existing GNU BFD ld and gold linkers. However, the authors of + existing GNU BFD ld and gold linkers. However, the authors of lld are not constrained by strict compatibility where it would hamper performance or desired functionality.

        @@ -2169,8 +2216,7 @@ Ports Management Team Website Ports Management Team on Twitter Ports Management Team on Facebook - Ports Management Team on Google+ + Ports Management Team on Google+ @@ -2178,13 +2224,13 @@ PR count around 2,150. Of these PRs, 516 are unassigned. The last quarter saw 5,295 commits by 117 active committers. Compared to the preceding quarter, there is both a slight - increase in the number of PRs and the number of unassigned PRs, - and a slight decrease in the number of committers.

        + increase in the number of PRs and the number of unassigned + PRs, and a slight decrease in the number of committers.

        In the last quarter, four commits bits were taken in for safe - keeping: erwin, miwi, and sem left by their own request and jase - was inactive for more than 18 months. We welcomed two new - committers: Tobias Berner (tcberner) and Joseph Mingrone + keeping: erwin, miwi, and sem left by their own request and + jase was inactive for more than 18 months. We welcomed two + new committers: Tobias Berner (tcberner) and Joseph Mingrone (jrm).

        On the management side, erwin and miwi left portmgr. bapt @@ -2202,18 +2248,19 @@

        Some major user-visible ports were updated: Firefox to 49.0 and Firefox Extended Service Release to 45.4.0; Chromium to - 52.0.2743.116; the default version of gcc to 4.8.5; and - pkg itself to 1.8.7.

        + 52.0.2743.116; the default version of gcc to 4.8.5; + and pkg itself to 1.8.7.

        -

        Behind the scenes, antoine ran 24 exp-runs to validate various - package updates, framework changes, and changes to the base - system. bdrewery added two new package building machines, - supervised the package builds for 11.0-RELEASE, and added support - for building arm64 packages.

        +

        Behind the scenes, antoine ran 24 exp-runs to validate + various package updates, framework changes, and changes to the + base system. bdrewery added two new package building + machines, supervised the package builds for 11.0-RELEASE, and + added support for building arm64 packages.

        At EuroBSDCon, rene visited a presentation by Landry Breuil - <landry@openbsd.org> explaining how packages are built in - the OpenBSD world and explaining various design decisions.

        + <landry@openbsd.org> explaining how packages are built + in the OpenBSD world and explaining various design + decisions.