Index: head/en_US.ISO8859-1/htdocs/news/status/report-2016-04-2016-06.xml =================================================================== --- head/en_US.ISO8859-1/htdocs/news/status/report-2016-04-2016-06.xml (revision 49021) +++ head/en_US.ISO8859-1/htdocs/news/status/report-2016-04-2016-06.xml (revision 49022) @@ -1,247 +1,329 @@ April-June 2016
Introduction

The second quarter of 2016.

—Insert name here

Please submit status reports for the third quarter of 2016 by insert date here.

team &os; Team Reports proj Projects kern Kernel arch Architectures bin Userland Programs ports Ports doc Documentation misc Miscellaneous &os; Release Engineering Team &os; Release Engineering Team re@FreeBSD.org &os; 10.3-RELEASE schedule &os; 11.0-RELEASE schedule &os; development snapshots

The &os; Release Engineering Team is responsible for setting and publishing release schedules for official project releases of &os;, announcing code freezes and maintaining the respective branches, among other things.

The &os; Release Engineering Team completed the 10.3-RELEASE cycle late April, led by &a.marius;. The release was one week behind the original schedule, to accommodate for a few last minute critical issues that were essential to include in the final release.

The &os; 11.0-RELEASE cycle started late May, one month behind the orignal schedule. The schedule slip was primarily to accommodate for packaging the &os; base system with the pkg(8) utility. However, as work on this progressed, it became apparent that there were too many outstanding issues. As a result, packaged base will be a "beta" feature for 11.0-RELEASE, with the goal of promoting it to a first-class feature in 11.1-RELEASE, with additional provisions to ensure a seamless transition for earlier supported releases.

Despite the fact that packaged base is not going to be a prime feature for &os; 11.0-RELEASE, the Release Engineering Team would like to thank everyone who tested, provided patches, provided ideas and feedback, and in some cases, shot themselves in the foot due to bugs.

The &os; Foundation Obsoleting Rails 3 Torsten Zühlsdorff tz@FreeBSD.org

Ruby on Rails is the base for most of the rubygems in the Ports Collection. Currently, versions 3.2 and 4.2 coexist. Since Rails 3.2 is running out of support, the time has come to switch to 4.2.

While there is ongoing progress to remove Rails 3.2 from the ports tree, there are some major updates blocking this process. The most recent blocker was the outstanding update of www/redmine from 2.6 to 3.2. This has completed successfully, so we can now move on.

To help with porting or testing, feel free to contact me or the ruby@FreeBSD.org mailing list.

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

Allwinner SoCs are used in multiple hobbyist devboards and single board computers. Recently, support for these SoCs received many updates.

Theses tasks were completed during the second quarter of 2016:

Ongoing work:

SPI driver LCD Support Any unsupported hardware device that might be of interest. + + + Robust Mutexes + + + + + Konstantin + Belousov + + kib@FreeBSD.org + + + + Ed + Maste + + emaste@FreeBSD.org + + + + +

Now that the process-shared locks are implemented for our + POSIX threads implementation library, libthr, + the only major lacking feature for POSIX compliance is robust + mutexes. Robust mutexes allow the application to detect, and + theoretically, recover from crashes which occur while + modifying the shared state. The supported model is to protect + shared state by a pthread_mutex, and the crash is + detected as the thread termination while owning the mutex. A + thread might terminate alone, or it could be killed due to the + termination of the containing process. As such, the robust + attribute is applicable to both process-private and -shared + mutexes.

+ +

An application must be specifically modified to handle and + recover from failures. The pthread_mutex_lock() + function may return new error EOWNERDEAD, which + indicates that the previous owner of the lock terminated while + still owning the lock. Despite returning the non-zero value, + the lock is granted to the caller. In the simplest form, an + application may detect the error and refuse to operate until + the persistent shared data is recovered, such as by manual + reinitialization. More sophisticated applications could try + to automatically recover from the condition, in which case + pthread_mutex_consistent(3) must be called on the + lock before the unlock. However, such recovery can be + considered to be very hard. Still, even the detection of + inconsistent shared state is useful, since it avoids further + corruption and random faults of the affected application. +

+ +

It is curious but not unexpected that this interface is not + used widely. The only real-life application which utilizes it + is Samba. Using Samba with an updated FreeBSD base uncovered + minor bugs both in the FreeBSD robustness implementation, and + in Samba itself.

+ +

It is believed that libthr in FreeBSD 11 is + POSIX-compliant for large features. Further work is planned + to look at the lock structures inlining to remove overhead + and improve performance of the library.

+ +

Most of the implementation of the robustness feature + consisted of making small changes in the lock and unlock + paths, both in libthr and in kern_umtx.c. + This literally required reading all of the code dealing with + mutexes and conditional variables, which was something I + wanted to help future developers with. In the end, with the + help of Ed Maste, the man pages for umtx(2) and all + thr*(2) syscalls were written and added to the base + system's documentation set. +

+ + + The FreeBSD Foundation + + + Use the implementation in real-word applications and + report issues. + +