From 485eb2e5813c55f87501fd6d12c733766c300ac2 Mon Sep 17 00:00:00 2001 From: Warren Block Date: Tue, 12 Apr 2016 23:24:54 +0000 Subject: [PATCH] Convert back to LF line endings. --- .../news/status/report-2016-01-2016-03.xml | 3648 ++++++++--------- 1 file changed, 1824 insertions(+), 1824 deletions(-) diff --git a/en_US.ISO8859-1/htdocs/news/status/report-2016-01-2016-03.xml b/en_US.ISO8859-1/htdocs/news/status/report-2016-01-2016-03.xml index 31d2ecc07f..e46cc077f3 100644 --- a/en_US.ISO8859-1/htdocs/news/status/report-2016-01-2016-03.xml +++ b/en_US.ISO8859-1/htdocs/news/status/report-2016-01-2016-03.xml @@ -1,1824 +1,1824 @@ - - - - - - - - January-March - - 2016 - - -
- Introduction - -

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

- - This report covers &os;-related projects between January and - March 2016. This is the first of four reports planned for - 2016.

- -

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

- -

Thanks to all the reporters for the excellent work!

- -

The deadline for submissions covering the period from April - to June 2016 is July 7, 2016.

- ?> -
- - - team - - &os; Team Reports - - - - proj - - Projects - - - - kern - - Kernel - - - - arch - - Architectures - - - - bin - - Userland Programs - - - - ports - - Ports - - - - doc - - Documentation - - - - misc - - Miscellaneous - - - - Static Analysis of the &os; Kernel with PVS Studio - - - - - Warren - Block - - wblock@FreeBSD.org - - - - - PVS-Studio delved into the FreeBSD kernel - PVS Static Analysis Phabricator Review - - - -

In February, Program Verification Systems used their - PVS-Studio tool to run a static analysis of the &os; kernel. - A Phabricator review was created to allow developers to share - comments on the results. A number of bugs ranging from - trivial typos to redundant code to important logic errors were - found and fixed. Some results were false positives. Several - of these were addressed by changing code that misled the - static analyzer and could also mislead a human reader.

- -

The cooperation that Program Verification Systems offers to - open-source projects like &os; benefits everyone. We thank - them for sharing this analysis and their insights with us.

- - - - - doc-mid.jpg - - Spanish FAQ and Chinese Porter's Handbook - Translations - - - - - Warren - Block - - wblock@FreeBSD.org - - - - - Federico - Caminiti - - demian.fc@gmail.com - - - - - Carlos - J Puga Medina - - cpm@fbsd.es - - - - - Ruey-Cherng - Yu - - raycherng@gmail.com - - - - - Preguntas Frecuentes para FreeBSD 9.X y 10.X - FreeBSD Porter 手冊 - &os; Translators Mailing List - PO Translations - &os; Documentation Project Primer for New Contributors - - - -

Federico Caminiti created an entirely new Spanish translation - of the 31,000-word - FAQ - with editorial help from Carlos J Puga Medina.

- -

This landmark accomplishment marks the first use of the new - PO translation system to translate an entire book!

- -

Ruey-Cherng Yu has begun an ambitious Chinese translation - (zh_TW) of the 64,000-word - Porter's Handbook. - About half of the strings in the book have been translated so - far.

- - - - -

Help add and improve translations of &os; documents into - Spanish: - start of freebsd-translators thread.

- - - -

Help add and improve translations of &os; documents into - Chinese or other languages.

- - - - - - NFS server - - - - - Rick - Macklem - - rmacklem@FreeBSD.org - - - - - - -

A new option "-manage-gids" was added to the nfsuserd - daemon. This option tells the NFS server to use the list of - groups for a uid on the server and not the list of groups in - the NFS RPC request. Use of this option avoids the 16 group - limit for NFS RPCs using AUTH_SYS (the default).

- -

Work is ongoing with respect to development of pNFS support - for the NFS server using GlusterFS as a back end. This will - be a long term project with the eventual goal of allowing the - NFS server to scale beyond a single server system. Hopefully - it will be available for testing in late Spring 2016. pNFS - allows a NFSv4.1 client to do reads/writes directly to a data - server and not the NFS server.

- - - - -

Development of the pNFS server will be in need of testing - or it will never progress to a near production status. I - hope to have code available in FreeBSD's subversion projects - branch for testing in late spring 2016.

- - - - - - powerpcspe target - - - - - Justin - Hibbits - - jhibbits@FreeBSD.org - - - - - Source tree - - - -

The purpose of this is to enable use of the Signal Processing - Engine found in the NXP/Freescale e500v2 SoC. The SPE uses - opcodes overlapping with Altivec, so is mutually exclusive. - Additionally, the e500v2 does not have a traditional FPU, and - instead uses the SPE for all floating point operations (or - emulation as is currently done). Combined with the fact that - the SPE ABI is incompatible with traditional ABI, a new - MACHINE_ARCH is created to address this.

- -

A project branch has been created with the work. A - powerpcspe kernel boots on the RouterBoard RB800, and base - utilities run properly.

- - - - -

Potentially optimizing setjmp/longjmp to not use SPE unless - it's already been enabled. This would save the kernel - switch for processes that don't otherwise use the SPE. This - is a low priority task which may not be completed.

- - - - - - The Graphics stack on FreeBSD - - - - - FreeBSD Graphics team - - freebsd-x11@FreeBSD.org - - - - - Graphics stack roadmap and supported hardware matrix - Ports development tree on GitHub - FreeBSD Graphics Team at FOSDEM 2016 - GSoC 2016: link /dev entries to sysctl nodes - GSoC 2016: redesign libdevq - - - -

The major news for this quarter is the update of the i915 - driver in the kernel! The driver now matches Linux 3.8.13, so - it includes initial Haswell support. Linux 3.8 is already - three years old, but work continues to upgrade DRM further. - In particular, the move to linuxkpi was started.

- -

In the Ports tree, Mesa was updated to 11.1.2. The next minor - release, 11.2.0, is ready for testing in our development tree. - We also updated libclc to 0.2.0.20151006, a library used by - Mesa to provide OpenCL support.

- -

We attended FOSDEM 2016 in Brussels. Jean-S??bastien P??dron - gave a talk to explain the work of the graphics team and show - how people can contribute. It was well received and the - presentation was followed by interesting discussions. FOSDEM - was also a nice occasion to meet and talk again to the nice - "upstream" developers of the graphics stack.

- -

For the first year, we added two ideas for GSoC 2016: one for - a kernel task, one to redesign libdevq. Six students - submitted a proposal for those two ideas, that was unexpected! - We now need to decide which one we want to mentor and the - choice is difficult.

- -

The blog is still down. We started to work on a replacement. - We will probably go with a static generated website hosted on - GitHub pages.

- - - - -

See the "Graphics" wiki page for up-to-date - information.

- - - - - - ARM Allwinner SoC Support - - - - - Jared - McNeill - - jmcneill@freebsd.org - - - - - Emmanuel - Vadot - - manu@bidouilliste.com - - - - - Allwinner FreeBSD Wiki - - - -

Allwinner SoC are used in multiple hobbyist devboards and - single board computers. Recently, support for these SoC have - received a lot of updates

- -

Task done during first quarter :

- -
    -
  • I2C
    • -
  • HDMI output
    • -
  • Basic AXP209 support (Power Management Unit)
    • -
  • Switch to upstream DTS for most boards
    • -
  • Basic Support for A31/A31S SoC
    • -
  • RTC
    • -
  • Proper Pinmux/GPIO support
    • -
  • Audio Codec / Audio HDMI
    • -
  • A10/A20 DMA support
    • -
  • A20 now uses the GIC (General Interrupt Controller)
    • -
  • A20 now uses the ARM Generic Timer
    • -
- -

Ongoing task :

- -
    -
  • Switch to new clock framework - (In review)
    • - -
  • Convert A10 interrupt controller to INTRNG - (In review)
    • - -
  • OHCI support - (In review)
    • - -
  • Generic ALLWINNER kernel config file - (In review)
    • - -
  • A20/A31 NMI support - (In review)
    • - -
  • USB OTG
    • - -
  • Finish the switch to upstream DTS
    • - -
  • A83T SoC Support
    • - -
  • H3 SoC Support
    • -
- - - - -

SPI driver

- - - -

LCD Support

- - - -

Any unsupported hardware device that might be of - interest.

- - - - - - new "FreeBSD Mastery" books - - - - - Michael - Lucas - - mwlucas@michaelwlucas.com - - - - - FreeBSD Mastery: Specialty Filesystems - - - -

FreeBSD Mastery: Specialty Filesystems - is now available everywhere, in print and ebook.

- -

Lucas and Allan Jude have also finished writing "FreeBSD - Mastery: Advanced ZFS." It's in copyedit now, and should be - available before May 2016. Check - zfsbook.com for details.

- -

Lucas' next book, "PAM Mastery," has a whole bunch of FreeBSD - content in it.

- - - - -

Make grammar corrections to Advanced ZFS, get it in - print.

- - - - - - FreeBSD on Cavium ThunderX (arm64) - - - - - Dominik - Ermel - - der@semihalf.com - - - - - Wojciech - Macek - - wma@semihalf.com - - - - - Zbigniew - Bodek - - zbb@semihalf.com - - - - - - -

Since the last report &os; support for ThunderX has been - significantly improved and stabilized. Semihalf contributions - include the following items:

- -
    -
  • Support for the newest ThunderX chip revisions (Pass 2.0) - and current Cavium firmware. Backward compatibility is - maintained.
    • - -
  • Moved to using pci_host_generic.c as a main driver for the - internal PCIe bridge. Significant rework of PCIe code to - support both generic and ThunderX based platforms.
    • - -
  • Serious networking performance boost and bug fixes:
    • -
      -
    • Fixed race condition on Rx path causing very rare - ‘use after free’ issue
      • - -
    • Hardware L3 and L4 checksums support
      • - -
    • Hardware assisted TCP Segmentation Offloading - (TSO)
      • - -
    • Support for software Large Receive Offload (LRO)
      • - -
    • Various improvements to Tx and Rx paths and - configuration
      • -
    -
- -

The driver supports all available Ethernet connections (1, - 10, 30 Gbps) and system can can saturate 10 Gbps link (on Tx) - using 4 CPU cores.

- -
    -
  • Significantly improved overall I/O performance:
    • -
      -
    • Complete rework of copyin/copyout and bzero - functionalities
      • -
    - -
  • Other improvements:
    • -
      -
    • Support for interrupt to CPU binding (including - GICv3/ITS backends)
      • -
    -
- -

This work is integrated to the FreeBSD HEAD on on-going - basis.

- - - - Cavium - - - - Semihalf - - - - -

Support for multi Queue Set operation in VNIC

- - - - - - Updates to GDB - - - - - John - Baldwin - - jhb@FreeBSD.org - - - - -

The new thread target that directly uses ptrace(2) - was committed upstream and included in GDB 7.11. The port was - also updated to GDB 7.11.

- - - - -

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.

- - - -

Add support for debugging powerpc vector registers.

- - - -

Add support for catching system calls.

- - - -

Add support for $_siginfo.

- - - -

Add support for ELF auxv data via 'info auxv'.

- - - -

Implement 'info os' commands.

- - - -

Implement gdbserver for freebsd.

- - - - - - Native PCI-express HotPlug - - - - - John - Baldwin - - jhb@FreeBSD.org - - - - - Native PCI-express HotPlug support - - - -

A new implementation for support of native PCI-express - hotplug is present at the URL above. Much of the new code - lives in the PCI-PCI bridge driver to handle hotplug events - and manage the PCI-express slot registers. Additional changes - in the branch include adding new 'rescan' and 'delete' - commands to devctl(8) as well as support for - rescanning PCI busses.

- -

The current implementation has been tested on systems with - ExpressCard but could use additional testing, especially on - systems with other PCI-express HotPlug features such as - mechanical latches, attention buttons, indicators, etc.

- - - - -

Split branch into separate logical changes as commit - candidates.

- - - -

Additional testing.

- - - - - - KDE on FreeBSD - - - - KDE on FreeBSD team - kde@FreeBSD.org - - - - - KDE on FreeBSD website - Experimental KDE ports staging area - KDE on FreeBSD wiki - KDE/FreeBSD mailing list - Development repository for integrating KDE Frameworks 5 and Plasma 5 - - - -

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

- -

While the list of updates is shorter compared to the previous - quarter, the team remained busy and work on KDE Frameworks 5 - and Plasma 5 continues.

- -

This quarter, Tobias Berner, who has been driving our KDE - Frameworks 5 and Plasma 5 efforts from the beginning, received - a KDE commit bit, and has been putting it to good use by - upstreaming FreeBSD across several KDE repositories. Another - team highlight in the beginning of this year is the - (re)addition of another committer to our experimental - repository: Adriaan de Groot, a longtime KDE contributor who - also used to work on KDE and FreeBSD almost a decade ago when - our team was first formed. Welcome back, Ade!

- -

The following big updates were landed in the ports tree this - quarter. In many cases, we have also contributed patches to - the upstream projects.

- -
    -
  • CMake 3.4.2 and 3.5.0
    • - -
  • Calligra 2.9.11, the latest release of the integrated work - applications suite. We have managed to keep in sync with - the upstream releases since 2.9.10.
    • - -
  • KDE Telepathy was updated to 0.9.0 and Telepathy-Qt4 was - updated to 0.9.6.1, the latest upstream releases.
    • - -
  • The Qt 5 ports were finally updated to 5.5.1, which were - the latest stable version at the time.
    • - -
  • The first commit preparing the groundwork for KDE - Frameworks 5 and Plasma 5 - was - landed to the ports tree.
    • -
- -

In our experimental area51 repository, work on Qt 5.6.0 is - underway in our experimental repositories. Additionally, at - the time of writing it also contains KDE Frameworks 5.20.0, - Plasma 5.6.1 and KDE Applications 16.03.80.

- -

Users interested in testing those ports are encouraged to - follow the instructions in - our website - and report their results to our mailing list. Qt5 5.6.0 is in - our "qt-5.6" branch, and Plasma 5 and the rest is in the - "plasma5" branch.

- - - - -

Land the KDE Frameworks 5 and Plasma 5 ports to the - tree.

- - - -

Commit the DigiKam 4.14.0 update currently being worked on - in our experimental repository.

- - - - - - Process-Shared locks for libthr - - - - - Konstantin - Belousov - - - kib@FreeBSD.org - - - - -

POSIX specifies several kinds of pthread locks, for this - report the private and process-shared variants are considered. - Private locks can be used only by the threads of the same - process, which share the address space. Process-shared locks - can be used by threads from any process, assuming the process - can map the lock memory into its address space.

- -

Our libthr, the library implementing the POSIX threads and - locking operations, uses a pointer as the internal - representation behind a lock. The pointer contains the - address of the actual structure carrying the lock. This has - unfortunate consequences for implementing the - PTHREAD_PROCESS_SHARED attribute for locks, since - really only the pointer is shared when the lock is mapped into - distinct address spaces.

- -

A common opinion was that we have no choice but to break the - libthr Application Binary Interface (ABI) by changing the lock - types to be the actual lock structures (and padding for future - ABI extension). This is very painful for users, as our - previous experience with non-versioned libc and libc_r - shown.

- -

Instead, I proposed and implemented a scheme where - process-shared locks can be implemented without breaking the - ABI. The lock memory is used as a key into the system-global - hash of the shared memory objects (off-pages), which carry the - real lock structures.

- -

New umtx operations to create or look up the shared object, - by the memory key, were added. Libthr is modified to lookup - the object and use it for shared locks, instead of using - malloc() as for private locks.

- -

The pointer value in the user-visible lock type contains a - canary for shared locks. Libthr detects the canary and - switches into the shared-lock mode.

- -

The proposal of inlining the lock structures, besides the - drawbacks of breaking ABI, has its merits. Most important, - the inlining avoids the need of indirection. Another - important advantage over the off-page page approach is that no - off-page object needs to be maintained, and the lifecycle of - the shared lock naturally finishes with the destruction of the - shared memory, without explicit cleanup. Right now, off-pages - hook into vm object termination to avoid leakage, but long - liviness of the vnode vm object prolonges the off-page - existence for shared locks backed by files, however unlikely - they may be.

- -

Libthr with inlined locks become informally known as libthr2 - project, since the library name better be changed instead of - only bumping the library version. The rtld should ensure that - libthr and libthr2 do not become simultaneously loaded into a - single address space.

- - - The FreeBSD Foundation - - - -

Implement robust mutexes.

- - - -

Evaluate and implement libthr2.

- - - - - - Clusteradm - - - - clusteradm@freebsd.org - - - - - - -

-

    -
  • migrated services out of the hosting space in ISC - (peter, sbruno)
    • - -
  • begun migration of services into RootBSD hosting space - (peter, sbruno)
    • - -
  • collaborated with phabricator admin team to migrate to - new and improved host in NYI. (AllanJude, peter, - sbruno)
    • - -
  • installed new and beefier Jenkins machine(gnn, lwshu, - sbruno)
    • - -
  • still looking for more Asian mirrors for pkg,svn,ftp - (Japan, India). (sbruno)
    • - -
  • migration of Taiwanese mirror to new location completed. - (lwshu)
    • - -
  • clang/llvm buildbbot now hosted in the FreeBSD cluster - at NYI (sbruno, emaste)
    • - -
  • resolved UK mirror outtage with Bytemark (gavin, - peter)
    • -

- - - - - - Obsoleting Rails 3 - - - - - Torsten - Zühlsdorff - - ports@toco-domains.de - - - - - - -

Ruby on Rails is the base for most of the rubygems in the - portstree. Currently version 3.2 and 4.2 coexists, but since - Rails 3.2 runs out of support, the time has come to - switch.

- -

There is an ongoing progress to remove Rails 3.2 from the - ports tree. While many gems already work with the new version, - there are some exceptions. For example www/redmine needs a big - update (which is currently tested) because it depends on gems - which therefore depends on Rails 3.2.

- -

If you want to help porting or testing, feel free to contact - me or the mailinglist ruby@FreeBSD.org.

- - - - - - GitLab Port - - - - - Torsten - Zühlsdorff - - ports@toco-domains.de - - - - - - -

After nearly a year of work on this project, GitLab 8.5.5 was - committed into the ports tree. A big thanks to the enormous - number of people involved! Since GitLab is a fast moving - project, there is also ongoing work to stay in sync with - upstream. Have fun!

- - - - - - FreeBSD Build - - - - - Bryan - Drewery - - bdrewery@FreeBSD.org - - - - - - -

Build improvements for buildworld on head continue. - Some highlights include:

- -
    -
  • WITH_FAST_DEPEND was made default in r296668 and - later made the only option in r297434. The new depend code - avoids a 'make depend' tree walk and generates .depend files - during build as a side-effect of compiling. This is using - the -MF flags of the compiler. This speeds up the build by - 15-35%.
    • - -
  • PR 196193: - WITHOUT_CROSS_COMPILER was fixed to properly use - --sysroot which allows the option to work in more - cases. It is still unsafe when major compiler upgrades - occur. Further work is planned to improve that still.
    • - -
  • WITHOUT_TOOLCHAIN now properly builds.
    • -
- - - - EMC / Isilon Storage Division - - - - -

Opportunistically skipping the bootstrap compiler phase of - buildworld.

- - - -

Skipping the 'make obj' tree walk.

- - - -

Enabling WITH_META_MODE in buildworld to provide a - reliable incremental build using filemon(4) and bmake's - .MAKE.MODE=meta. This should not be confused with - WITH_DIRDEPS_BUILD which previously was named - WITH_META_MODE and is a drastically different build - system presented at BSDCan 2014 by Simon Gerraty.

- - - - - - Filemon performance/stability improvements - - - - - Bryan - Drewery - - bdrewery@FreeBSD.org - - - - - Mateusz - Guzik - - mjg@FreeBSD.org - - - - - - -

Filemon is a kernel module for tracing which files a command - creates, reads, writes or executes. It allows tracking build - dependencies in combination with bmake's meta mode. Bmake - will store filemon's output in a .meta file along with the - build command and later use this to check if any of the files - references are missing or modified, or if the build command - changes, to trigger a rebuild of the target. It provides the - same functionality as compiler -MF flags but for everything. - It will be critical for buildworld's WITH_META_MODE - (which is the normal buildworld but just using filemon) to - provide a reliable incremental build without even the need of - .depend files or compiler -MF flags. This will allow - -DNO_CLEAN to work all of the time.

- -

Over this quarter filemon on head was improved for stability - and performance. It no longer causes every syscall it hooks - into to loop on processes looking for a matching filemon - struct. It now just attaches directly to the struct proc with - its own pointer. This improves performance by reducing lock - contention during a build using it. Much other work went into - improving error handling and other stability issues in the - module as well.

- -

All of this work was done by Bryan Drewery, sponsored by EMC, - but much help and identification of bugs was provided by - Mateusz Guzik.

- - - - EMC / Isilon Storage Division - - - - -

Improving credential handling

- - - -

Improving EVENTHANDLER performance

- - - -

Possibly providing a framework for syscallenter/syscallret - hooking to avoid the need to hook syscalls as Filemon - does.

- - - - - - AmigaOne X5000 support - - - - - Justin - Hibbits - - jhibbits@freebsd.org - - - - - - - - -

A continuation of the Book-E QorIQ support enhancements by - Semihalf dating back to 2012.

- -

The AmigaOne X5000 series of AmigaOS compatible systems uses - the Freescale QorIQ series of SoCs for a desktop-class form - factor. The work here entails adding support for the e5500 - core itself, in addition to support for the SoC - peripherals.

- -

Currently most code is checked in to enable basic support: - dTSEC (ethernet), core support (e500mc, e5500). Additionally, - as part of this, rman, the kernel resource manager, was - enhanced to use uintmax_t for resources. This allows devices - to be physically above the 4GB boundary on 32-bit systems. - With a statically compiled device tree, it boots to multiuser - mode, with nfsroot, and can be used as normal (serial and ssh - logins once configured).

- - - - Alex Perez (Inertial Computing) - - - - -

eSDHC driver. Work has been started on this, hijacking the - imx_sdhc.c from Ian Lepore, but there are still bugs: - missing DMA from the iMX driver, and odd timeouts after the - system starts up.

- - - -

SATA support. There is a WIP driver for the SATA - controller, but it's currently very slow, about 11MB/s on a - SATA 2 link. It currently relies on a 10ms delay on every - SATA transaction, in order for it to be even somewhat - stable. Without this delay, the disk scan never works and I - haven't yet figured out why.

- - - -

Local console (VGA) support. It currently boots with a - serial console. vgapci0 is seen if there's a PCIe graphics - card, but vt(4) doesn't attach to it yet.

- - - -

64-bit support. The CPU on the board is a P5020, a 64-bit - e5500 dual-core SoC. Currently, booke support in FreeBSD is - 32-bit only.

- - - -

SMP. SMP support on Book-E hardware is currently - broken.

- - - -

U-boot support. Currently this uses a compiled-in device - tree, but it would be preferred for it to use the device - tree provided by u-boot, or at least the Linux-compatible - device tree.

- - - -

More work is needed on the DPAA front (Datapath - Acceleration Architecture) to improve the ethernet driver, - and utilize the SEC engine for crypto, random(4), - and IPSec.

- - - - - - The FreeBSD German Documentation Project - - - - - Bj??rn - Heidotting - - bhd@FreeBSD.org - - - - - Benedict - Reuschling - - bcr@FreeBSD.org - - - - - Johann - Kois - - jkois@FreeBSD.org - - - - - Homepage of the FreeBSD German Documentation Project - - - -

The FreeBSD German Documentation Project translates FreeBSD's - documentation (handbook, articles, website, etc.) into the - German language.

- -

Due to the tireless effort of Bj??rn Heidotting, we made huge - improvements in catching up with the translation of the German - handbook. Benedict helped with reviewing the changes using - FreeBSD's review system Phabricator, which helped a lot. We - now have the following handbook chapters in sync with the - latest version in the English tree:

- -
    -
  • filesystems
    • - -
  • kernelconfig
    • - -
  • ports
    • - -
  • x11
    • -
- -

We try to keep up the good work, while also looking at new - ways to translate like the PO/gettext-based system. We are - always looking for volunteers who are interested in - translating small sections or even entire documents. The - process is relatively easy and contributors don't have to know - much to get started. The members of the FreeBSD German - Documentation Team are also willing to mentor people who are - interested in helping out.

- - - - -

Translate more documents.

- - - - - - ELF Tool Chain tools - - - - - Ed - Maste - - emaste@FreeBSD.org - - - - - ELF Tool Chain web site - - - -

The ELF Tool Chain project provides BSD-licensed - implementations of compilation tools and libraries for - building and analyzing ELF objects. The project began as part - of &os; but later became an independent project to encourage - wider participation from others in the open-source developer - community.

- -

The ELF Tool Chain project released version 0.7.1 in - February. We have been tracking snapshots of the upstream - repository in &os; and are not blocked waiting for releases to - update. Having an official release brings the benefit of - broader testing and visibility within other open source - projects.

- -

In the first quarter of 2016 The ELF Tool Chain tools were - updated to a snapshot of upstream SVN revision 3400, which - is close to the 0.7.1 release. Additional bug fixes were - committed to FreeBSD and subsequently merged into the upstream - repository.

- -

ELF Tool Chain's elfcopy(1) is now installed as - objcopy(1) by default as it is a viable replacement - for the base system and ports tree.

- -

Significant improvements were made to the - elfcopy(1), readelf(1), and - elfdump(1) tools, including better MIPS, RISC-V, and - AArch64 support.

- - - The &os; Foundation - - - -

Fix issues found by fuzzing inputs to the tools.

- - - -

Add automatic support for separate debug files.

- - - -

Investigate replacement objdump, ld and as - implementations.

- - - - - - Infiniband - - - - - Hans Petter - Selasky - - hselasky@freebsd.org - - - - - Call for testing - - - -

Mellanox is working on a big infiniband update towards - Mellanox OFED v3.2 of the infiniband stack in &os;. The - updates include both userland and kernel. If you are using - infiniband with &os;, patches are available in the link above - which can be downloaded and applied to a recent &os;-head - checkout.

- - - - Mellanox Technologies - - - - - - - FreeBSD Integration Services (BIS) - - - - - Sepherosa - Ziehau - - sepherosa@gmail.com - - - - - Howard - Su - - howard0su@gmail.com - - - - - Hongjiang - Zhang - - honzhan@microsoft.com - - - - - Dexuan - Cui - - decui@microsoft.com - - - - - FreeBSD Virtual Machines on Microsoft Hyper-V - Supported Linux and FreeBSD virtual machines for Hyper-V on Windows - - - -

When &os; virtual machines (VMs) run on Hyper-V, using - Hyper-V synthetic devices is recommended to get the best - network and storage performance and make full use of all the - benefits that Hyper-V provides. The collection of drivers that - are required to use Hyper-V synthetic devices in FreeBSD are - known as FreeBSD Integration Services (BIS). Some of the BIS - drivers (like network and storage drivers) have existed in - FreeBSD 9.x and 10.x for years, but there are still some - performance and stability issues and bugs. Compared with - Windows and Linux VMs, the current BIS lacks some useful - features, e.g., live virtual machine backup, TRIM/Unmap, the - support for UEFI VM (boot from UEFI), etc.

- -

During the past quarter, we made a great progress on the - performance tuning for Hyper-V network driver. We also - refactored and cleaned up the VMBus driver, and fixed some - important bugs. All the work makes FreeBSD VMs run even better - on Hyper-V and the Hyper-V based cloud platform Azure!

- -

Our work during 2016Q1 is documented below:

- -

Optimizing the performance of Hyper-V network driver

- -
    -
  • We added the LRO (Large Receive Offloading) support to the - driver and properly handled the ACK packets. This - effectively reduced the CPU cycles used in the TCP/IP stack - and dramatically boosted the network performance!
    • - -
  • We enabled the vRSS (virtual Receive Side Scaling) support - for the driver. This greatly improved the network - performance for SMP virtual machine (VM).
    • - -
  • We used a separate Tx kernel thread to relieve the Rx - thread of transmitting packets (the Rx thread tried to - transmit packets after receiving ACKs), so the Rx thread can - receive packets and send ACKs faster.
    • - -
  • Now we can reach a VM-to-VM throughput of 9.1Gbps on a - host with 10Gbps physical NIC, and over 20Gbps on a host - with 40Gbps NIC, and meanwhile the CPUs still have plenty of - cycles for applications.
    • - -
  • We also enabled IP header checksum offloading, and RX - checksum offloading for UDP.
    • - -
  • Further performance tuning is working in progress.
    • -
- -

Refactoring and Cleaning up the VMBus driver code

- -
    -
  • Instead of using swi threads directly, now we use per-CPU - taskqueue_create_fast() threads for event and message - handling, making the code more FreeBSD conventional.
    • - -
  • Made a lot of cleanup to the hv_utils code (HeartBeat, - TimeSync and Shutdown) and we are further cleaning up the - KVP code.
    • - -
  • Used a new message/interrupt slot for Hyper-V timer, so - the handling of timer and non-timer messages can be - distinguished, fixing a potential issue.
    • - -
  • Instead of finding an available IDT vector by hacking, - we're changing to use the normal method, i.e., - lapic_ipi_alloc().
    • - -
  • We're modularizing the Hyper-V modules: 1) they will be - loaded in the loader; 2) we're going to enhance devd(8) to - improve the hot plug case.
    • -
- -

Bug Fixing

- -
    -
  • Fixed the "spurious multiple disks" issue (PR 206630 ??? - FreeBSD 10.2 on Windows 10 and 2016 server may not boot due - to multiple invalid disks issue) in the Hyper-V storage - driver and now FreeBSD VM can reliably boot on Win10 and - 2016 hosts.
    • - -
  • Fixed the OACTIVE issue (PR 207297 - [Hyper-V] FreeBSD - 10.2 on hyperv lost network under heavy load for - OACTIVE).
    • - -
  • Fixed TSC calibration issue (PR 208238 - [Hyper-V] TSC - frequency is not correctly detected: "calcru: runtime went - backwards") and we won't see the "runtime went backwards" - messages anymore!
    • - -
  • Fixed the "very slow terminal" issue of 11-CURRENT by - enabling text mode when we're running on hypervisors.
    • - -
  • Fixed the "unknown dhcp option value 0xf5" issue in - dhclient(8) by asking dhclient(8) to - ignore the option and &os; VM on Azure can reliably get IP - now.
    • -
- -

Found a workaround for PR 20824 ([Hyper-V] VM network may not - work over virtual switch based on wireless NIC): add - "net.link.ether.inet.max_age=60" in /etc/sysctl.conf.

- -

We plan to add support for live virtual machine backup, - TRIM/Unmap, and UEFI VMs (Hyper-V Generation-2 VMs).

- -

We published errata (FreeBSD-EN-16:04.hyperv, - FreeBSD-EN-16:05.hv_netvsc) with the Release Engineering team, - so 10.1 and 10.2 users can easily get the fixes of KVP and TCP - checksum by upgrading the system.

- -

We published BIS test cases for Hyper-V on github: - https://github.com/FreeBSDonHyper-V/Test-BIS and we are going - to publish the test cases for Azure soon.

- -

This project is sponsored by Microsoft.

- - - - Microsoft - - - - - - - Ports Collection - - - - - Frederic - Culot - - portmgr-secretary@FreeBSD.org - - - - &os; Ports Management Team - portmgr@FreeBSD.org - - - - - - - - - - - - -

As of the end of Q1 the ports tree holds a bit more - than 25,000 ports, and the PR count is below 1,900. The - activity on the ports tree remains steady, with almost 7,000 - commits performed by around 120 active committers.

- -

On the problem reports front, the encouraging trend - observed during the previous quarter is confirmed, with again - a significant increase in the number of PRs fixed during Q1. - Indeed, almost 2,400 reports were fixed, which allows us to go - below the threshold value of 2,000 open PRs.

- -

In Q1 3 commit bits were taken in for safekeeping, - following an inactivity period of more than 18 months (milki, - brian), or on committer's request (mmoll). We had one - returning committer (fluffy) who had his commit bit - reinstated. Two new developers were granted a ports commit bit - (Olivier Cochard-Labbe, Christoph Moench-Tegeder).

- -

On the management side, we had the pleasure to welcome back - miwi to the portmgr team.

- -

On QA side 39 exp-runs were performed to validate sensitive - updates or cleanups. The most noticeable change might be the - removal of the now unneeded ${PORTSDIR} when - specifying dependencies in Makefiles (see the - /usr/ports/CHANGES entry dated 20160402). Amongst - other noticeable changes are the update to ruby 2.3, ruby-gems - to 2.5.1, CMake to 3.5.0, clang to 3.8.0-r258968, Qt5 to - 5.5.1, Gnome to 3.18, boost to 1.60.0, the update of libc++ in - base to 3.8.0 release, and the enabling of LLVM libunwind by - default on x86. The CentOS ports were also updated. Some - infrastructure changes included the switch from - bsd.gnome.mk and bsd.mate.mk to the simpler - Uses/gnome.mk and Uses/mate.mk. Some work - was also done to improve poudriere builds by reducing - dependency calculation and general overheads.

- - - - -

We would like to remind everyone that the ports tree is - built and run by volunteers, and any help is greatly - appreciated. A great amount of effort was spent on the ports - front in Q1, which allowed us to decrease the number of - pending problem reports significantly, as well as on the - ports infrastructure. Many thanks to all who - contributed!

- - - - - - Address Space Layout Randomization - - - - - Konstantin - Belousov - - kib@FreeBSD.org - - - - - Ed - Maste - - emaste@FreeBSD.org - - - - - Patch home. - - - -

I wrote a small and straightforward yet feature-packed patch - to implement ASLR for &os; available for broader testing.

- -

With this change, randomization is applied to all non-fixed - mappings. By randomization I mean the base address for the - mapping is selected with a guaranteed amount of entropy - (bits). If the mapping was requested to be superpage aligned, - the randomization honours the superpage attributes.

- -

The randomization is done on a best-effort basis - that is, - the allocator falls back to a first fit strategy if - fragmentation prevents entropy injection. It is trivial to - implement a strong mode where failure to guarantee the - requested amount of entropy results in mapping request - failure, but I do not consider that to be usable.

- -

I have not fine-tuned the amount of entropy injected right - now. It is only a quantitive change that will not change the - implementation. The current amount is controlled by - aslr_pages_rnd.

- -

To not spoil coalescing optimizations, to reduce the page - table fragmentation inherent to ASLR, and to keep the - transient superpage promotion for the malloced memory, the - locality is implemented for anonymous private mappings, which - are automatically grouped until fragmentation kicks in. The - initial location for the anon group range is, of course, - randomized. After some additional tuning, the measures - appeared to be quite effective. In particular, very - address-space hungry build of PyPy 5.0 on i386 successfully - finished with the most aggressive functionality of the patch - activated.

- -

The default mode keeps the sbrk area unpopulated by other - mappings, but this can be turned off, which gives much more - breathing bits on the small AS architectures (funny that - 32bits is considered small). This is tied with the question - of following an application's hint about the mmap(2) - base address. Testing shows that ignoring the hint does not - affect the function of common applications, but I would expect - more demanding code could break. By default sbrk is preserved - and mmap hints are satisfied, which can be changed by using - the kern.elf{32,64}.aslr_care_sbrk sysctl (currently enabled - by default for wider testing).

- -

Stack gap, W^X, shared page randomization, KASLR and other - techniques are explicitely out of scope of this work.

- -

The paxtest results for the run with the previous version 5 - of the patch applied and aggresively tuned can be seen at the - https://www.kib.kiev.ua/kib/aslr/paxtest.log . For - comparison, the run on Fedora 23 on the same machine is at - https://www.kib.kiev.ua/kib/aslr/fedora.log .

- -

ASLR is enabled on per-ABI basis, and currently it is only - enabled on native i386 and amd64 (including compat 32bit) and - ARMv6 ABIs. I expect to test and enable ASLR for arm64 as - well, later.

- -

The procctl(2) control for ASLR is implemented, but - I have not provided a userspace wrapper around the syscall. - In fact, the most reasonable control needed is per-image and - not per-process, but we have no tradition to put the - kernel-read attributes into the extattrs of binary, so I am - still pondering that part and this also explains the - non-written tool.

- -

Thanks to Oliver Pinter and Shawn Webb of the HardenedBSD - project for pursuing ASLR for &os;. Although this work is - not based on theirs, it was inspired by their efforts.

- -

Thanks to Ed Maste, Robert Watson, John Baldwin, and Alan Cox - for some discussions about the patch, and for The FreeBSD - Foundation for directing me.

- -

Bartek Rutkowski tested PyPy builds on i386, and David Naylor - helped with the port which was at point of turbulence and - upgrade during the work.

- - - The FreeBSD Foundation - - - - RCTL disk IO Limits - - - - - Edward Tomasz - Napierała - - trasz@FreeBSD.org - - - - - - -

An important missing piece of the RCTL resource limits - framework was the ability to limit file system throughput. - This project aims to fill that hole by making it possible to - add RCTL rules for read bytes per second (BPS), write BPS, - read I/O operations per second (IOPS), and write IOPS, and - adding a new throttling mechanism, to slow down offending - processes when a limit gets hit.

- -

The code has been committed and will ship with &os; - 11.0-RELEASE.

- - - - -

Additional testing

- - - -

Simplify locking, getting rid of rctl_lock altogether

- - - -

Improve statistics gathering by make it possible for - rctl -u to retrieve usage counters at a fixed point - of time

- - - -

Use the new throttling mechanism for %CPU limits

- - - - - The FreeBSD Foundation - - - - - Qt 5.6 on Raspberry Pi - - - - - Oleksandr - Tymoshenko - - gonzo@FreeBSD.org - - - - - Qt 5.6 on FreeBSD/Pi - - - -

Qt 5.6 is a great framework to build embedded GUI application - so when Qt 5.6 was released it was natural to bring it up on - Raspberry Pi. Current Qt support in ports is very - Xorg-centric so as a proof of concept I created an - experimental qt56-base and qt56-multimedia.

- -

qt56-base can be configured for a generic ARM device with the - scfb video driver and specifically for Raspberry Pi in which - case it supports eglfs mode with hardware OpenGL - acceleration.

- - - - -

Check how embedded use cases can be fit into current - bsd.qt.mk or whether a new port should be - introduced.

- - - - - - FDT overlay support in ubldr - - - - - Oleksandr - Tymoshenko - - gonzo@FreeBSD.org - - - - - ubldr patch - - - -

A flattened device tree is a way to keep the hardware - description separated from code. During the boot process, the - loader passes a pointer to the device-tree blob to the kernel - and the kernel instantiates and attaches drivers according to - the information in the blob.

- -

This approach does not work if hardware is expansible. For - example, the Raspberry Pi and Beaglebone Black have the - concept of capes or shields: snap-on PCBs that are connected - to IO headers on the main board and provide additional - functionality like an LCD screen or GPS receiver. These - shields can be described by their own device trees and these - trees can be overlaid on the base tree by the boot loader, - thus providing an accurate description to the kernel.

- -

The proposed patch add this functionality to ubldr. The user - can specify a comma-separated list of overlays as U-Boot or - the loader fdt_overlays variable and ubldr will load them from - /boot/dtb/ directory and do the overlaying.

- - - - - + + + + + + + + January-March + + 2016 + + +
+ Introduction + +

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

+ + This report covers &os;-related projects between January and + March 2016. This is the first of four reports planned for + 2016.

+ +

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

+ +

Thanks to all the reporters for the excellent work!

+ +

The deadline for submissions covering the period from April + to June 2016 is July 7, 2016.

+ ?> +
+ + + team + + &os; Team Reports + + + + proj + + Projects + + + + kern + + Kernel + + + + arch + + Architectures + + + + bin + + Userland Programs + + + + ports + + Ports + + + + doc + + Documentation + + + + misc + + Miscellaneous + + + + Static Analysis of the &os; Kernel with PVS Studio + + + + + Warren + Block + + wblock@FreeBSD.org + + + + + PVS-Studio delved into the FreeBSD kernel + PVS Static Analysis Phabricator Review + + + +

In February, Program Verification Systems used their + PVS-Studio tool to run a static analysis of the &os; kernel. + A Phabricator review was created to allow developers to share + comments on the results. A number of bugs ranging from + trivial typos to redundant code to important logic errors were + found and fixed. Some results were false positives. Several + of these were addressed by changing code that misled the + static analyzer and could also mislead a human reader.

+ +

The cooperation that Program Verification Systems offers to + open-source projects like &os; benefits everyone. We thank + them for sharing this analysis and their insights with us.

+ + + + + doc-mid.jpg + + Spanish FAQ and Chinese Porter's Handbook + Translations + + + + + Warren + Block + + wblock@FreeBSD.org + + + + + Federico + Caminiti + + demian.fc@gmail.com + + + + + Carlos + J Puga Medina + + cpm@fbsd.es + + + + + Ruey-Cherng + Yu + + raycherng@gmail.com + + + + + Preguntas Frecuentes para FreeBSD 9.X y 10.X + FreeBSD Porter 手冊 + &os; Translators Mailing List + PO Translations + &os; Documentation Project Primer for New Contributors + + + +

Federico Caminiti created an entirely new Spanish translation + of the 31,000-word + FAQ + with editorial help from Carlos J Puga Medina.

+ +

This landmark accomplishment marks the first use of the new + PO translation system to translate an entire book!

+ +

Ruey-Cherng Yu has begun an ambitious Chinese translation + (zh_TW) of the 64,000-word + Porter's Handbook. + About half of the strings in the book have been translated so + far.

+ + + + +

Help add and improve translations of &os; documents into + Spanish: + start of freebsd-translators thread.

+ + + +

Help add and improve translations of &os; documents into + Chinese or other languages.

+ + + + + + NFS server + + + + + Rick + Macklem + + rmacklem@FreeBSD.org + + + + + + +

A new option "-manage-gids" was added to the nfsuserd + daemon. This option tells the NFS server to use the list of + groups for a uid on the server and not the list of groups in + the NFS RPC request. Use of this option avoids the 16 group + limit for NFS RPCs using AUTH_SYS (the default).

+ +

Work is ongoing with respect to development of pNFS support + for the NFS server using GlusterFS as a back end. This will + be a long term project with the eventual goal of allowing the + NFS server to scale beyond a single server system. Hopefully + it will be available for testing in late Spring 2016. pNFS + allows a NFSv4.1 client to do reads/writes directly to a data + server and not the NFS server.

+ + + + +

Development of the pNFS server will be in need of testing + or it will never progress to a near production status. I + hope to have code available in FreeBSD's subversion projects + branch for testing in late spring 2016.

+ + + + + + powerpcspe target + + + + + Justin + Hibbits + + jhibbits@FreeBSD.org + + + + + Source tree + + + +

The purpose of this is to enable use of the Signal Processing + Engine found in the NXP/Freescale e500v2 SoC. The SPE uses + opcodes overlapping with Altivec, so is mutually exclusive. + Additionally, the e500v2 does not have a traditional FPU, and + instead uses the SPE for all floating point operations (or + emulation as is currently done). Combined with the fact that + the SPE ABI is incompatible with traditional ABI, a new + MACHINE_ARCH is created to address this.

+ +

A project branch has been created with the work. A + powerpcspe kernel boots on the RouterBoard RB800, and base + utilities run properly.

+ + + + +

Potentially optimizing setjmp/longjmp to not use SPE unless + it's already been enabled. This would save the kernel + switch for processes that don't otherwise use the SPE. This + is a low priority task which may not be completed.

+ + + + + + The Graphics stack on FreeBSD + + + + + FreeBSD Graphics team + + freebsd-x11@FreeBSD.org + + + + + Graphics stack roadmap and supported hardware matrix + Ports development tree on GitHub + FreeBSD Graphics Team at FOSDEM 2016 + GSoC 2016: link /dev entries to sysctl nodes + GSoC 2016: redesign libdevq + + + +

The major news for this quarter is the update of the i915 + driver in the kernel! The driver now matches Linux 3.8.13, so + it includes initial Haswell support. Linux 3.8 is already + three years old, but work continues to upgrade DRM further. + In particular, the move to linuxkpi was started.

+ +

In the Ports tree, Mesa was updated to 11.1.2. The next minor + release, 11.2.0, is ready for testing in our development tree. + We also updated libclc to 0.2.0.20151006, a library used by + Mesa to provide OpenCL support.

+ +

We attended FOSDEM 2016 in Brussels. Jean-S??bastien P??dron + gave a talk to explain the work of the graphics team and show + how people can contribute. It was well received and the + presentation was followed by interesting discussions. FOSDEM + was also a nice occasion to meet and talk again to the nice + "upstream" developers of the graphics stack.

+ +

For the first year, we added two ideas for GSoC 2016: one for + a kernel task, one to redesign libdevq. Six students + submitted a proposal for those two ideas, that was unexpected! + We now need to decide which one we want to mentor and the + choice is difficult.

+ +

The blog is still down. We started to work on a replacement. + We will probably go with a static generated website hosted on + GitHub pages.

+ + + + +

See the "Graphics" wiki page for up-to-date + information.

+ + + + + + ARM Allwinner SoC Support + + + + + Jared + McNeill + + jmcneill@freebsd.org + + + + + Emmanuel + Vadot + + manu@bidouilliste.com + + + + + Allwinner FreeBSD Wiki + + + +

Allwinner SoC are used in multiple hobbyist devboards and + single board computers. Recently, support for these SoC have + received a lot of updates

+ +

Task done during first quarter :

+ +
    +
  • I2C
    • +
  • HDMI output
    • +
  • Basic AXP209 support (Power Management Unit)
    • +
  • Switch to upstream DTS for most boards
    • +
  • Basic Support for A31/A31S SoC
    • +
  • RTC
    • +
  • Proper Pinmux/GPIO support
    • +
  • Audio Codec / Audio HDMI
    • +
  • A10/A20 DMA support
    • +
  • A20 now uses the GIC (General Interrupt Controller)
    • +
  • A20 now uses the ARM Generic Timer
    • +
+ +

Ongoing task :

+ +
    +
  • Switch to new clock framework + (In review)
    • + +
  • Convert A10 interrupt controller to INTRNG + (In review)
    • + +
  • OHCI support + (In review)
    • + +
  • Generic ALLWINNER kernel config file + (In review)
    • + +
  • A20/A31 NMI support + (In review)
    • + +
  • USB OTG
    • + +
  • Finish the switch to upstream DTS
    • + +
  • A83T SoC Support
    • + +
  • H3 SoC Support
    • +
+ + + + +

SPI driver

+ + + +

LCD Support

+ + + +

Any unsupported hardware device that might be of + interest.

+ + + + + + new "FreeBSD Mastery" books + + + + + Michael + Lucas + + mwlucas@michaelwlucas.com + + + + + FreeBSD Mastery: Specialty Filesystems + + + +

FreeBSD Mastery: Specialty Filesystems + is now available everywhere, in print and ebook.

+ +

Lucas and Allan Jude have also finished writing "FreeBSD + Mastery: Advanced ZFS." It's in copyedit now, and should be + available before May 2016. Check + zfsbook.com for details.

+ +

Lucas' next book, "PAM Mastery," has a whole bunch of FreeBSD + content in it.

+ + + + +

Make grammar corrections to Advanced ZFS, get it in + print.

+ + + + + + FreeBSD on Cavium ThunderX (arm64) + + + + + Dominik + Ermel + + der@semihalf.com + + + + + Wojciech + Macek + + wma@semihalf.com + + + + + Zbigniew + Bodek + + zbb@semihalf.com + + + + + + +

Since the last report &os; support for ThunderX has been + significantly improved and stabilized. Semihalf contributions + include the following items:

+ +
    +
  • Support for the newest ThunderX chip revisions (Pass 2.0) + and current Cavium firmware. Backward compatibility is + maintained.
    • + +
  • Moved to using pci_host_generic.c as a main driver for the + internal PCIe bridge. Significant rework of PCIe code to + support both generic and ThunderX based platforms.
    • + +
  • Serious networking performance boost and bug fixes:
    • +
      +
    • Fixed race condition on Rx path causing very rare + ‘use after free’ issue
      • + +
    • Hardware L3 and L4 checksums support
      • + +
    • Hardware assisted TCP Segmentation Offloading + (TSO)
      • + +
    • Support for software Large Receive Offload (LRO)
      • + +
    • Various improvements to Tx and Rx paths and + configuration
      • +
    +
+ +

The driver supports all available Ethernet connections (1, + 10, 30 Gbps) and system can can saturate 10 Gbps link (on Tx) + using 4 CPU cores.

+ +
    +
  • Significantly improved overall I/O performance:
    • +
      +
    • Complete rework of copyin/copyout and bzero + functionalities
      • +
    + +
  • Other improvements:
    • +
      +
    • Support for interrupt to CPU binding (including + GICv3/ITS backends)
      • +
    +
+ +

This work is integrated to the FreeBSD HEAD on on-going + basis.

+ + + + Cavium + + + + Semihalf + + + + +

Support for multi Queue Set operation in VNIC

+ + + + + + Updates to GDB + + + + + John + Baldwin + + jhb@FreeBSD.org + + + + +

The new thread target that directly uses ptrace(2) + was committed upstream and included in GDB 7.11. The port was + also updated to GDB 7.11.

+ + + + +

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.

+ + + +

Add support for debugging powerpc vector registers.

+ + + +

Add support for catching system calls.

+ + + +

Add support for $_siginfo.

+ + + +

Add support for ELF auxv data via 'info auxv'.

+ + + +

Implement 'info os' commands.

+ + + +

Implement gdbserver for freebsd.

+ + + + + + Native PCI-express HotPlug + + + + + John + Baldwin + + jhb@FreeBSD.org + + + + + Native PCI-express HotPlug support + + + +

A new implementation for support of native PCI-express + hotplug is present at the URL above. Much of the new code + lives in the PCI-PCI bridge driver to handle hotplug events + and manage the PCI-express slot registers. Additional changes + in the branch include adding new 'rescan' and 'delete' + commands to devctl(8) as well as support for + rescanning PCI busses.

+ +

The current implementation has been tested on systems with + ExpressCard but could use additional testing, especially on + systems with other PCI-express HotPlug features such as + mechanical latches, attention buttons, indicators, etc.

+ + + + +

Split branch into separate logical changes as commit + candidates.

+ + + +

Additional testing.

+ + + + + + KDE on FreeBSD + + + + KDE on FreeBSD team + kde@FreeBSD.org + + + + + KDE on FreeBSD website + Experimental KDE ports staging area + KDE on FreeBSD wiki + KDE/FreeBSD mailing list + Development repository for integrating KDE Frameworks 5 and Plasma 5 + + + +

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

+ +

While the list of updates is shorter compared to the previous + quarter, the team remained busy and work on KDE Frameworks 5 + and Plasma 5 continues.

+ +

This quarter, Tobias Berner, who has been driving our KDE + Frameworks 5 and Plasma 5 efforts from the beginning, received + a KDE commit bit, and has been putting it to good use by + upstreaming FreeBSD across several KDE repositories. Another + team highlight in the beginning of this year is the + (re)addition of another committer to our experimental + repository: Adriaan de Groot, a longtime KDE contributor who + also used to work on KDE and FreeBSD almost a decade ago when + our team was first formed. Welcome back, Ade!

+ +

The following big updates were landed in the ports tree this + quarter. In many cases, we have also contributed patches to + the upstream projects.

+ +
    +
  • CMake 3.4.2 and 3.5.0
    • + +
  • Calligra 2.9.11, the latest release of the integrated work + applications suite. We have managed to keep in sync with + the upstream releases since 2.9.10.
    • + +
  • KDE Telepathy was updated to 0.9.0 and Telepathy-Qt4 was + updated to 0.9.6.1, the latest upstream releases.
    • + +
  • The Qt 5 ports were finally updated to 5.5.1, which were + the latest stable version at the time.
    • + +
  • The first commit preparing the groundwork for KDE + Frameworks 5 and Plasma 5 + was + landed to the ports tree.
    • +
+ +

In our experimental area51 repository, work on Qt 5.6.0 is + underway in our experimental repositories. Additionally, at + the time of writing it also contains KDE Frameworks 5.20.0, + Plasma 5.6.1 and KDE Applications 16.03.80.

+ +

Users interested in testing those ports are encouraged to + follow the instructions in + our website + and report their results to our mailing list. Qt5 5.6.0 is in + our "qt-5.6" branch, and Plasma 5 and the rest is in the + "plasma5" branch.

+ + + + +

Land the KDE Frameworks 5 and Plasma 5 ports to the + tree.

+ + + +

Commit the DigiKam 4.14.0 update currently being worked on + in our experimental repository.

+ + + + + + Process-Shared locks for libthr + + + + + Konstantin + Belousov + + + kib@FreeBSD.org + + + + +

POSIX specifies several kinds of pthread locks, for this + report the private and process-shared variants are considered. + Private locks can be used only by the threads of the same + process, which share the address space. Process-shared locks + can be used by threads from any process, assuming the process + can map the lock memory into its address space.

+ +

Our libthr, the library implementing the POSIX threads and + locking operations, uses a pointer as the internal + representation behind a lock. The pointer contains the + address of the actual structure carrying the lock. This has + unfortunate consequences for implementing the + PTHREAD_PROCESS_SHARED attribute for locks, since + really only the pointer is shared when the lock is mapped into + distinct address spaces.

+ +

A common opinion was that we have no choice but to break the + libthr Application Binary Interface (ABI) by changing the lock + types to be the actual lock structures (and padding for future + ABI extension). This is very painful for users, as our + previous experience with non-versioned libc and libc_r + shown.

+ +

Instead, I proposed and implemented a scheme where + process-shared locks can be implemented without breaking the + ABI. The lock memory is used as a key into the system-global + hash of the shared memory objects (off-pages), which carry the + real lock structures.

+ +

New umtx operations to create or look up the shared object, + by the memory key, were added. Libthr is modified to lookup + the object and use it for shared locks, instead of using + malloc() as for private locks.

+ +

The pointer value in the user-visible lock type contains a + canary for shared locks. Libthr detects the canary and + switches into the shared-lock mode.

+ +

The proposal of inlining the lock structures, besides the + drawbacks of breaking ABI, has its merits. Most important, + the inlining avoids the need of indirection. Another + important advantage over the off-page page approach is that no + off-page object needs to be maintained, and the lifecycle of + the shared lock naturally finishes with the destruction of the + shared memory, without explicit cleanup. Right now, off-pages + hook into vm object termination to avoid leakage, but long + liviness of the vnode vm object prolonges the off-page + existence for shared locks backed by files, however unlikely + they may be.

+ +

Libthr with inlined locks become informally known as libthr2 + project, since the library name better be changed instead of + only bumping the library version. The rtld should ensure that + libthr and libthr2 do not become simultaneously loaded into a + single address space.

+ + + The FreeBSD Foundation + + + +

Implement robust mutexes.

+ + + +

Evaluate and implement libthr2.

+ + + + + + Clusteradm + + + + clusteradm@freebsd.org + + + + + + +

+

    +
  • migrated services out of the hosting space in ISC + (peter, sbruno)
    • + +
  • begun migration of services into RootBSD hosting space + (peter, sbruno)
    • + +
  • collaborated with phabricator admin team to migrate to + new and improved host in NYI. (AllanJude, peter, + sbruno)
    • + +
  • installed new and beefier Jenkins machine(gnn, lwshu, + sbruno)
    • + +
  • still looking for more Asian mirrors for pkg,svn,ftp + (Japan, India). (sbruno)
    • + +
  • migration of Taiwanese mirror to new location completed. + (lwshu)
    • + +
  • clang/llvm buildbbot now hosted in the FreeBSD cluster + at NYI (sbruno, emaste)
    • + +
  • resolved UK mirror outtage with Bytemark (gavin, + peter)
    • +

+ + + + + + Obsoleting Rails 3 + + + + + Torsten + Zühlsdorff + + ports@toco-domains.de + + + + + + +

Ruby on Rails is the base for most of the rubygems in the + portstree. Currently version 3.2 and 4.2 coexists, but since + Rails 3.2 runs out of support, the time has come to + switch.

+ +

There is an ongoing progress to remove Rails 3.2 from the + ports tree. While many gems already work with the new version, + there are some exceptions. For example www/redmine needs a big + update (which is currently tested) because it depends on gems + which therefore depends on Rails 3.2.

+ +

If you want to help porting or testing, feel free to contact + me or the mailinglist ruby@FreeBSD.org.

+ + + + + + GitLab Port + + + + + Torsten + Zühlsdorff + + ports@toco-domains.de + + + + + + +

After nearly a year of work on this project, GitLab 8.5.5 was + committed into the ports tree. A big thanks to the enormous + number of people involved! Since GitLab is a fast moving + project, there is also ongoing work to stay in sync with + upstream. Have fun!

+ + + + + + FreeBSD Build + + + + + Bryan + Drewery + + bdrewery@FreeBSD.org + + + + + + +

Build improvements for buildworld on head continue. + Some highlights include:

+ +
    +
  • WITH_FAST_DEPEND was made default in r296668 and + later made the only option in r297434. The new depend code + avoids a 'make depend' tree walk and generates .depend files + during build as a side-effect of compiling. This is using + the -MF flags of the compiler. This speeds up the build by + 15-35%.
    • + +
  • PR 196193: + WITHOUT_CROSS_COMPILER was fixed to properly use + --sysroot which allows the option to work in more + cases. It is still unsafe when major compiler upgrades + occur. Further work is planned to improve that still.
    • + +
  • WITHOUT_TOOLCHAIN now properly builds.
    • +
+ + + + EMC / Isilon Storage Division + + + + +

Opportunistically skipping the bootstrap compiler phase of + buildworld.

+ + + +

Skipping the 'make obj' tree walk.

+ + + +

Enabling WITH_META_MODE in buildworld to provide a + reliable incremental build using filemon(4) and bmake's + .MAKE.MODE=meta. This should not be confused with + WITH_DIRDEPS_BUILD which previously was named + WITH_META_MODE and is a drastically different build + system presented at BSDCan 2014 by Simon Gerraty.

+ + + + + + Filemon performance/stability improvements + + + + + Bryan + Drewery + + bdrewery@FreeBSD.org + + + + + Mateusz + Guzik + + mjg@FreeBSD.org + + + + + + +

Filemon is a kernel module for tracing which files a command + creates, reads, writes or executes. It allows tracking build + dependencies in combination with bmake's meta mode. Bmake + will store filemon's output in a .meta file along with the + build command and later use this to check if any of the files + references are missing or modified, or if the build command + changes, to trigger a rebuild of the target. It provides the + same functionality as compiler -MF flags but for everything. + It will be critical for buildworld's WITH_META_MODE + (which is the normal buildworld but just using filemon) to + provide a reliable incremental build without even the need of + .depend files or compiler -MF flags. This will allow + -DNO_CLEAN to work all of the time.

+ +

Over this quarter filemon on head was improved for stability + and performance. It no longer causes every syscall it hooks + into to loop on processes looking for a matching filemon + struct. It now just attaches directly to the struct proc with + its own pointer. This improves performance by reducing lock + contention during a build using it. Much other work went into + improving error handling and other stability issues in the + module as well.

+ +

All of this work was done by Bryan Drewery, sponsored by EMC, + but much help and identification of bugs was provided by + Mateusz Guzik.

+ + + + EMC / Isilon Storage Division + + + + +

Improving credential handling

+ + + +

Improving EVENTHANDLER performance

+ + + +

Possibly providing a framework for syscallenter/syscallret + hooking to avoid the need to hook syscalls as Filemon + does.

+ + + + + + AmigaOne X5000 support + + + + + Justin + Hibbits + + jhibbits@freebsd.org + + + + + + + + +

A continuation of the Book-E QorIQ support enhancements by + Semihalf dating back to 2012.

+ +

The AmigaOne X5000 series of AmigaOS compatible systems uses + the Freescale QorIQ series of SoCs for a desktop-class form + factor. The work here entails adding support for the e5500 + core itself, in addition to support for the SoC + peripherals.

+ +

Currently most code is checked in to enable basic support: + dTSEC (ethernet), core support (e500mc, e5500). Additionally, + as part of this, rman, the kernel resource manager, was + enhanced to use uintmax_t for resources. This allows devices + to be physically above the 4GB boundary on 32-bit systems. + With a statically compiled device tree, it boots to multiuser + mode, with nfsroot, and can be used as normal (serial and ssh + logins once configured).

+ + + + Alex Perez (Inertial Computing) + + + + +

eSDHC driver. Work has been started on this, hijacking the + imx_sdhc.c from Ian Lepore, but there are still bugs: + missing DMA from the iMX driver, and odd timeouts after the + system starts up.

+ + + +

SATA support. There is a WIP driver for the SATA + controller, but it's currently very slow, about 11MB/s on a + SATA 2 link. It currently relies on a 10ms delay on every + SATA transaction, in order for it to be even somewhat + stable. Without this delay, the disk scan never works and I + haven't yet figured out why.

+ + + +

Local console (VGA) support. It currently boots with a + serial console. vgapci0 is seen if there's a PCIe graphics + card, but vt(4) doesn't attach to it yet.

+ + + +

64-bit support. The CPU on the board is a P5020, a 64-bit + e5500 dual-core SoC. Currently, booke support in FreeBSD is + 32-bit only.

+ + + +

SMP. SMP support on Book-E hardware is currently + broken.

+ + + +

U-boot support. Currently this uses a compiled-in device + tree, but it would be preferred for it to use the device + tree provided by u-boot, or at least the Linux-compatible + device tree.

+ + + +

More work is needed on the DPAA front (Datapath + Acceleration Architecture) to improve the ethernet driver, + and utilize the SEC engine for crypto, random(4), + and IPSec.

+ + + + + + The FreeBSD German Documentation Project + + + + + Bj??rn + Heidotting + + bhd@FreeBSD.org + + + + + Benedict + Reuschling + + bcr@FreeBSD.org + + + + + Johann + Kois + + jkois@FreeBSD.org + + + + + Homepage of the FreeBSD German Documentation Project + + + +

The FreeBSD German Documentation Project translates FreeBSD's + documentation (handbook, articles, website, etc.) into the + German language.

+ +

Due to the tireless effort of Bj??rn Heidotting, we made huge + improvements in catching up with the translation of the German + handbook. Benedict helped with reviewing the changes using + FreeBSD's review system Phabricator, which helped a lot. We + now have the following handbook chapters in sync with the + latest version in the English tree:

+ +
    +
  • filesystems
    • + +
  • kernelconfig
    • + +
  • ports
    • + +
  • x11
    • +
+ +

We try to keep up the good work, while also looking at new + ways to translate like the PO/gettext-based system. We are + always looking for volunteers who are interested in + translating small sections or even entire documents. The + process is relatively easy and contributors don't have to know + much to get started. The members of the FreeBSD German + Documentation Team are also willing to mentor people who are + interested in helping out.

+ + + + +

Translate more documents.

+ + + + + + ELF Tool Chain tools + + + + + Ed + Maste + + emaste@FreeBSD.org + + + + + ELF Tool Chain web site + + + +

The ELF Tool Chain project provides BSD-licensed + implementations of compilation tools and libraries for + building and analyzing ELF objects. The project began as part + of &os; but later became an independent project to encourage + wider participation from others in the open-source developer + community.

+ +

The ELF Tool Chain project released version 0.7.1 in + February. We have been tracking snapshots of the upstream + repository in &os; and are not blocked waiting for releases to + update. Having an official release brings the benefit of + broader testing and visibility within other open source + projects.

+ +

In the first quarter of 2016 The ELF Tool Chain tools were + updated to a snapshot of upstream SVN revision 3400, which + is close to the 0.7.1 release. Additional bug fixes were + committed to FreeBSD and subsequently merged into the upstream + repository.

+ +

ELF Tool Chain's elfcopy(1) is now installed as + objcopy(1) by default as it is a viable replacement + for the base system and ports tree.

+ +

Significant improvements were made to the + elfcopy(1), readelf(1), and + elfdump(1) tools, including better MIPS, RISC-V, and + AArch64 support.

+ + + The &os; Foundation + + + +

Fix issues found by fuzzing inputs to the tools.

+ + + +

Add automatic support for separate debug files.

+ + + +

Investigate replacement objdump, ld and as + implementations.

+ + + + + + Infiniband + + + + + Hans Petter + Selasky + + hselasky@freebsd.org + + + + + Call for testing + + + +

Mellanox is working on a big infiniband update towards + Mellanox OFED v3.2 of the infiniband stack in &os;. The + updates include both userland and kernel. If you are using + infiniband with &os;, patches are available in the link above + which can be downloaded and applied to a recent &os;-head + checkout.

+ + + + Mellanox Technologies + + + + + + + FreeBSD Integration Services (BIS) + + + + + Sepherosa + Ziehau + + sepherosa@gmail.com + + + + + Howard + Su + + howard0su@gmail.com + + + + + Hongjiang + Zhang + + honzhan@microsoft.com + + + + + Dexuan + Cui + + decui@microsoft.com + + + + + FreeBSD Virtual Machines on Microsoft Hyper-V + Supported Linux and FreeBSD virtual machines for Hyper-V on Windows + + + +

When &os; virtual machines (VMs) run on Hyper-V, using + Hyper-V synthetic devices is recommended to get the best + network and storage performance and make full use of all the + benefits that Hyper-V provides. The collection of drivers that + are required to use Hyper-V synthetic devices in FreeBSD are + known as FreeBSD Integration Services (BIS). Some of the BIS + drivers (like network and storage drivers) have existed in + FreeBSD 9.x and 10.x for years, but there are still some + performance and stability issues and bugs. Compared with + Windows and Linux VMs, the current BIS lacks some useful + features, e.g., live virtual machine backup, TRIM/Unmap, the + support for UEFI VM (boot from UEFI), etc.

+ +

During the past quarter, we made a great progress on the + performance tuning for Hyper-V network driver. We also + refactored and cleaned up the VMBus driver, and fixed some + important bugs. All the work makes FreeBSD VMs run even better + on Hyper-V and the Hyper-V based cloud platform Azure!

+ +

Our work during 2016Q1 is documented below:

+ +

Optimizing the performance of Hyper-V network driver

+ +
    +
  • We added the LRO (Large Receive Offloading) support to the + driver and properly handled the ACK packets. This + effectively reduced the CPU cycles used in the TCP/IP stack + and dramatically boosted the network performance!
    • + +
  • We enabled the vRSS (virtual Receive Side Scaling) support + for the driver. This greatly improved the network + performance for SMP virtual machine (VM).
    • + +
  • We used a separate Tx kernel thread to relieve the Rx + thread of transmitting packets (the Rx thread tried to + transmit packets after receiving ACKs), so the Rx thread can + receive packets and send ACKs faster.
    • + +
  • Now we can reach a VM-to-VM throughput of 9.1Gbps on a + host with 10Gbps physical NIC, and over 20Gbps on a host + with 40Gbps NIC, and meanwhile the CPUs still have plenty of + cycles for applications.
    • + +
  • We also enabled IP header checksum offloading, and RX + checksum offloading for UDP.
    • + +
  • Further performance tuning is working in progress.
    • +
+ +

Refactoring and Cleaning up the VMBus driver code

+ +
    +
  • Instead of using swi threads directly, now we use per-CPU + taskqueue_create_fast() threads for event and message + handling, making the code more FreeBSD conventional.
    • + +
  • Made a lot of cleanup to the hv_utils code (HeartBeat, + TimeSync and Shutdown) and we are further cleaning up the + KVP code.
    • + +
  • Used a new message/interrupt slot for Hyper-V timer, so + the handling of timer and non-timer messages can be + distinguished, fixing a potential issue.
    • + +
  • Instead of finding an available IDT vector by hacking, + we're changing to use the normal method, i.e., + lapic_ipi_alloc().
    • + +
  • We're modularizing the Hyper-V modules: 1) they will be + loaded in the loader; 2) we're going to enhance devd(8) to + improve the hot plug case.
    • +
+ +

Bug Fixing

+ +
    +
  • Fixed the "spurious multiple disks" issue (PR 206630 ??? + FreeBSD 10.2 on Windows 10 and 2016 server may not boot due + to multiple invalid disks issue) in the Hyper-V storage + driver and now FreeBSD VM can reliably boot on Win10 and + 2016 hosts.
    • + +
  • Fixed the OACTIVE issue (PR 207297 - [Hyper-V] FreeBSD + 10.2 on hyperv lost network under heavy load for + OACTIVE).
    • + +
  • Fixed TSC calibration issue (PR 208238 - [Hyper-V] TSC + frequency is not correctly detected: "calcru: runtime went + backwards") and we won't see the "runtime went backwards" + messages anymore!
    • + +
  • Fixed the "very slow terminal" issue of 11-CURRENT by + enabling text mode when we're running on hypervisors.
    • + +
  • Fixed the "unknown dhcp option value 0xf5" issue in + dhclient(8) by asking dhclient(8) to + ignore the option and &os; VM on Azure can reliably get IP + now.
    • +
+ +

Found a workaround for PR 20824 ([Hyper-V] VM network may not + work over virtual switch based on wireless NIC): add + "net.link.ether.inet.max_age=60" in /etc/sysctl.conf.

+ +

We plan to add support for live virtual machine backup, + TRIM/Unmap, and UEFI VMs (Hyper-V Generation-2 VMs).

+ +

We published errata (FreeBSD-EN-16:04.hyperv, + FreeBSD-EN-16:05.hv_netvsc) with the Release Engineering team, + so 10.1 and 10.2 users can easily get the fixes of KVP and TCP + checksum by upgrading the system.

+ +

We published BIS test cases for Hyper-V on github: + https://github.com/FreeBSDonHyper-V/Test-BIS and we are going + to publish the test cases for Azure soon.

+ +

This project is sponsored by Microsoft.

+ + + + Microsoft + + + + + + + Ports Collection + + + + + Frederic + Culot + + portmgr-secretary@FreeBSD.org + + + + &os; Ports Management Team + portmgr@FreeBSD.org + + + + + + + + + + + + +

As of the end of Q1 the ports tree holds a bit more + than 25,000 ports, and the PR count is below 1,900. The + activity on the ports tree remains steady, with almost 7,000 + commits performed by around 120 active committers.

+ +

On the problem reports front, the encouraging trend + observed during the previous quarter is confirmed, with again + a significant increase in the number of PRs fixed during Q1. + Indeed, almost 2,400 reports were fixed, which allows us to go + below the threshold value of 2,000 open PRs.

+ +

In Q1 3 commit bits were taken in for safekeeping, + following an inactivity period of more than 18 months (milki, + brian), or on committer's request (mmoll). We had one + returning committer (fluffy) who had his commit bit + reinstated. Two new developers were granted a ports commit bit + (Olivier Cochard-Labbe, Christoph Moench-Tegeder).

+ +

On the management side, we had the pleasure to welcome back + miwi to the portmgr team.

+ +

On QA side 39 exp-runs were performed to validate sensitive + updates or cleanups. The most noticeable change might be the + removal of the now unneeded ${PORTSDIR} when + specifying dependencies in Makefiles (see the + /usr/ports/CHANGES entry dated 20160402). Amongst + other noticeable changes are the update to ruby 2.3, ruby-gems + to 2.5.1, CMake to 3.5.0, clang to 3.8.0-r258968, Qt5 to + 5.5.1, Gnome to 3.18, boost to 1.60.0, the update of libc++ in + base to 3.8.0 release, and the enabling of LLVM libunwind by + default on x86. The CentOS ports were also updated. Some + infrastructure changes included the switch from + bsd.gnome.mk and bsd.mate.mk to the simpler + Uses/gnome.mk and Uses/mate.mk. Some work + was also done to improve poudriere builds by reducing + dependency calculation and general overheads.

+ + + + +

We would like to remind everyone that the ports tree is + built and run by volunteers, and any help is greatly + appreciated. A great amount of effort was spent on the ports + front in Q1, which allowed us to decrease the number of + pending problem reports significantly, as well as on the + ports infrastructure. Many thanks to all who + contributed!

+ + + + + + Address Space Layout Randomization + + + + + Konstantin + Belousov + + kib@FreeBSD.org + + + + + Ed + Maste + + emaste@FreeBSD.org + + + + + Patch home. + + + +

I wrote a small and straightforward yet feature-packed patch + to implement ASLR for &os; available for broader testing.

+ +

With this change, randomization is applied to all non-fixed + mappings. By randomization I mean the base address for the + mapping is selected with a guaranteed amount of entropy + (bits). If the mapping was requested to be superpage aligned, + the randomization honours the superpage attributes.

+ +

The randomization is done on a best-effort basis - that is, + the allocator falls back to a first fit strategy if + fragmentation prevents entropy injection. It is trivial to + implement a strong mode where failure to guarantee the + requested amount of entropy results in mapping request + failure, but I do not consider that to be usable.

+ +

I have not fine-tuned the amount of entropy injected right + now. It is only a quantitive change that will not change the + implementation. The current amount is controlled by + aslr_pages_rnd.

+ +

To not spoil coalescing optimizations, to reduce the page + table fragmentation inherent to ASLR, and to keep the + transient superpage promotion for the malloced memory, the + locality is implemented for anonymous private mappings, which + are automatically grouped until fragmentation kicks in. The + initial location for the anon group range is, of course, + randomized. After some additional tuning, the measures + appeared to be quite effective. In particular, very + address-space hungry build of PyPy 5.0 on i386 successfully + finished with the most aggressive functionality of the patch + activated.

+ +

The default mode keeps the sbrk area unpopulated by other + mappings, but this can be turned off, which gives much more + breathing bits on the small AS architectures (funny that + 32bits is considered small). This is tied with the question + of following an application's hint about the mmap(2) + base address. Testing shows that ignoring the hint does not + affect the function of common applications, but I would expect + more demanding code could break. By default sbrk is preserved + and mmap hints are satisfied, which can be changed by using + the kern.elf{32,64}.aslr_care_sbrk sysctl (currently enabled + by default for wider testing).

+ +

Stack gap, W^X, shared page randomization, KASLR and other + techniques are explicitely out of scope of this work.

+ +

The paxtest results for the run with the previous version 5 + of the patch applied and aggresively tuned can be seen at the + https://www.kib.kiev.ua/kib/aslr/paxtest.log . For + comparison, the run on Fedora 23 on the same machine is at + https://www.kib.kiev.ua/kib/aslr/fedora.log .

+ +

ASLR is enabled on per-ABI basis, and currently it is only + enabled on native i386 and amd64 (including compat 32bit) and + ARMv6 ABIs. I expect to test and enable ASLR for arm64 as + well, later.

+ +

The procctl(2) control for ASLR is implemented, but + I have not provided a userspace wrapper around the syscall. + In fact, the most reasonable control needed is per-image and + not per-process, but we have no tradition to put the + kernel-read attributes into the extattrs of binary, so I am + still pondering that part and this also explains the + non-written tool.

+ +

Thanks to Oliver Pinter and Shawn Webb of the HardenedBSD + project for pursuing ASLR for &os;. Although this work is + not based on theirs, it was inspired by their efforts.

+ +

Thanks to Ed Maste, Robert Watson, John Baldwin, and Alan Cox + for some discussions about the patch, and for The FreeBSD + Foundation for directing me.

+ +

Bartek Rutkowski tested PyPy builds on i386, and David Naylor + helped with the port which was at point of turbulence and + upgrade during the work.

+ + + The FreeBSD Foundation + + + + RCTL disk IO Limits + + + + + Edward Tomasz + Napierała + + trasz@FreeBSD.org + + + + + + +

An important missing piece of the RCTL resource limits + framework was the ability to limit file system throughput. + This project aims to fill that hole by making it possible to + add RCTL rules for read bytes per second (BPS), write BPS, + read I/O operations per second (IOPS), and write IOPS, and + adding a new throttling mechanism, to slow down offending + processes when a limit gets hit.

+ +

The code has been committed and will ship with &os; + 11.0-RELEASE.

+ + + + +

Additional testing

+ + + +

Simplify locking, getting rid of rctl_lock altogether

+ + + +

Improve statistics gathering by make it possible for + rctl -u to retrieve usage counters at a fixed point + of time

+ + + +

Use the new throttling mechanism for %CPU limits

+ + + + + The FreeBSD Foundation + + + + + Qt 5.6 on Raspberry Pi + + + + + Oleksandr + Tymoshenko + + gonzo@FreeBSD.org + + + + + Qt 5.6 on FreeBSD/Pi + + + +

Qt 5.6 is a great framework to build embedded GUI application + so when Qt 5.6 was released it was natural to bring it up on + Raspberry Pi. Current Qt support in ports is very + Xorg-centric so as a proof of concept I created an + experimental qt56-base and qt56-multimedia.

+ +

qt56-base can be configured for a generic ARM device with the + scfb video driver and specifically for Raspberry Pi in which + case it supports eglfs mode with hardware OpenGL + acceleration.

+ + + + +

Check how embedded use cases can be fit into current + bsd.qt.mk or whether a new port should be + introduced.

+ + + + + + FDT overlay support in ubldr + + + + + Oleksandr + Tymoshenko + + gonzo@FreeBSD.org + + + + + ubldr patch + + + +

A flattened device tree is a way to keep the hardware + description separated from code. During the boot process, the + loader passes a pointer to the device-tree blob to the kernel + and the kernel instantiates and attaches drivers according to + the information in the blob.

+ +

This approach does not work if hardware is expansible. For + example, the Raspberry Pi and Beaglebone Black have the + concept of capes or shields: snap-on PCBs that are connected + to IO headers on the main board and provide additional + functionality like an LCD screen or GPS receiver. These + shields can be described by their own device trees and these + trees can be overlaid on the base tree by the boot loader, + thus providing an accurate description to the kernel.

+ +

The proposed patch add this functionality to ubldr. The user + can specify a comma-separated list of overlays as U-Boot or + the loader fdt_overlays variable and ubldr will load them from + /boot/dtb/ directory and do the overlaying.

+ + + + +