Skip site navigation (1) Skip section navigation (2)

Introduction

This report covers FreeBSD-related projects between January and March 2014. This is the first of four reports planned for 2014.

The first quarter of 2014 was, again, a hectic and productive time for FreeBSD. The Ports team released their landmark first quarterly stable branch. FreeBSD continues to grow on the ARM architecture, now running on an ARM-based ChromeBook. SMP is now possible on multi-core ARM systems. bhyve, the native FreeBSD hypervisor, continues to improve. An integral test suite is taking shape, and the Jenkins Continuous Integration system has been implemented. FreeBSD patches to GCC are being forward-ported, and LLDB, the Clang/LLVM debugger is being ported. Desktop use has also seen improvements, with work on Gnome, KDE, Xfce, KMS video drivers, X.org, and vt, the new console driver which supports KMS and Unicode. Linux and Wine binary compatibility layers have been improved. UEFI booting support has been merged to head. The FreeBSD Foundation continues to assist in moving FreeBSD forward, sponsoring conferences and meetings and numerous development projects. And these are only some of the things that happened! Read on for even more.

Thanks to all the reporters for the excellent work! This report contains 41 entries and we hope you enjoy reading it.

The deadline for submissions covering between April and June 2014 is July 7th, 2014.

FreeBSD Team Reports

Projects

Kernel

Architectures

Userland Programs

Ports

Documentation

Miscellaneous


    FreeBSD Team Reports


    FreeBSD Cluster Administration Team

    Contact: FreeBSD Cluster Administration Team <admins@>

    The FreeBSD Cluster Administration Team consists of the people responsible for administering the machines that the project relies on for its distributed work and communications to be synchronised. In this quarter, the team has worked on the following:

    • Assimilated master email configurations into a single source control repository.
    • Moved the FreeBSD web server CGI services to a new location (sponsored).
    • Further enhanced upon our internal monitoring utilities.
    • Added a Russian pkg(8) mirror, hosted by Yandex.
    • Moved the FreeBSD�Foundation web services to a new server (sponsored).

    This project was sponsored by The FreeBSD Foundation.

    FreeBSD Core Team

    Contact: FreeBSD Core Team <[email protected]>

    The FreeBSD Core Team constitutes the project's Board of Directors, responsible for deciding the project's overall goals and direction as well as managing specific areas of the FreeBSD project landscape.

    The first quarter of 2014 was very active for the Core Team. John Baldwin and David Chisnall kept coordinating the work required for providing a newer version of X.Org for 9.x and 10.x systems. Now that vt(4), a successor to syscons(4) that offers a KMS-enabled console, has been merged to both stable/9 and stable/10, an alternative pkg(8) repository is in preparation for wider testing of vt(4) and the new X.Org version. In addition to that, John Baldwin published the policy on licenses for new files and files with non-standard licenses. Thanks to the efforts of Gavin Atkinson, FreeBSD has again made it into the Google Summer of Code program, for the tenth time. David Chisnall reported that both libc++ and libstdc++ can now be built, as all of the standards-compliant implementations of the required numerical functions have been added.

    The Core Team conducted an annual review among the Project teams and hats, where team members had to declare whether they wished to continue their service. As a result, Florian Smeets replaced David Wolfskill in the lead role of the Postmaster Team, and Glen Barber assumed the head Release Engineer position from Ken Smith. The Core Team congratulates Florian and Glen, and thanks David and Ken for their long-standing work.

    The Core Team approved chartering the Ports Security Team, which is established to maintain security updates for the ported applications. In coordination with the Port Management Team, pkg_tools was eventually deprecated and tagged with an End-of-Life date, in order to clear the way for pkg(8). The Port Management Team also requested a way to make it possible to track userland ABI and KBI changes reliably for the Ports Collection. Ideally this can be achieved by increasing the value of __FreeBSD_version on each fix, therefore the corresponding discussion concluded in freezing the ABI note tag for releases in order to keep the size of binary patches for freebsd-update(8) low. A related Errata Notice is about to be published soon.

    Only a single commit bit was taken for safekeeping. We did not have new committers to the src/ repository in this quarter.

    FreeBSD Documentation Engineering Team

    Links
    Announcement of Warren Block's addition URL: http://lists.freebsd.org/pipermail/freebsd-doc/2014-February/023265.html

    Contact: FreeBSD Documentation Engineering Team <[email protected]>

    The FreeBSD Documentation Engineering Team is responsible for defining and following up on the documentation goals for the committers in the Documentation project. The team is pleased to announce a new member — Warren Block. In early March, the FreeBSD Documentation Engineering Team members assumed responsibility for the FreeBSD Webmaster Team.

    FreeBSD Port Management Team

    Links
    URL: http://www.FreeBSD.org/ports/
    URL: http://www.freebsd.org/doc/en_US.ISO8859-1/articles/contributing-ports/
    URL: http://portsmon.freebsd.org/index.html
    URL: http://www.freebsd.org/portmgr/index.html
    URL: http://blogs.freebsdish.org/portmgr/
    URL: http://www.twitter.com/freebsd_portmgr/
    URL: http://www.facebook.com/portmgr
    URL: http://plus.google.com/communities/108335846196454338383

    Contact: Thomas Abthorpe <[email protected]>
    Contact: Frederic Culot <[email protected]>
    Contact: FreeBSD Port Management Team <[email protected]>

    The role of the FreeBSD Port Management Team is to ensure that the FreeBSD Ports Developer community provides a ports collection that is functional, stable, up-to-date and full-featured. It is also to coordinate among the committers and developers who work on it.

    The ports tree slowly approaches the 25,000 ports threshold, while the PR count exceeds 1,800. In the first quarter, we added four new committers, took in three commit bits for safe keeping, and reinstated one commit bit.

    In January, the longest serving port manager, Joe Marcus Clarke, stepped down from his active duties on the team. At a similar time Ion-Mihai Tetcu also stepped down from his duties. Fortunately, as a result of the first portmgr-lurkers intake, we were able to replace them with Mathieu Arnold and Antoine Brodin.

    Commencing March 1, the second intake of portmgr-lurkers started active duty on portmgr for a four month duration. The next two candidates are Alexey Dokuchaev and Frederic Culot.

    This quarter also saw the release of the first quarterly branch, namely 2014Q1. This branch is intended to provide a stable and high-quality ports tree, with patches related to security fixes as well as packaging and runtime fixes being backported from head.

    Ongoing maintenance goes into redports.org, including QAT runs and ports and security updates.

    Open tasks:

    1. As previously noted, many PRs continue to languish. We would like to see committers dedicate themselves to closing as many as possible.

    FreeBSD Postmaster Team

    Contact: FreeBSD Postmaster Team <[email protected]>

    The FreeBSD Postmaster Team is responsible for mail being correctly delivered to the committers' email addresses, ensuring that the mailing lists work, and should take measures against possible disruptions of project mail services, such as having troll-, spam- and virus-filters.

    In the first quarter of 2014, the team has implemented these items that may be interest of the general public:

    • Continued a discussion on current and possible future mail and spam filtering.
    • Discovered more of what needs to be done for a new year (with respect to email archives), did what we could, and recorded the steps for next time.
    • Added Kubilay Kocak to donations, requested by Pietro Cerutti.
    • Added Warren Block to doceng.
    • Made sure portmgr receives bounces for pkg-fallout messages.
    • Created a jenkins-admin mail alias.
    • Enabled Mailman password reminder emails again.
    • Discovered that all Mailman cron jobs were disabled in November during upgrades. Enabled those again. This caused problems like digests not being sent.

    FreeBSD Release Engineering Team

    Links
    FreeBSD�9.3-RELEASE schedule URL: http://www.FreeBSD.org/releases/9.3R/schedule.html
    FreeBSD�9.3-RELEASE todo list URL: http://www.FreeBSD.org/releases/9.3R/todo.html
    FreeBSD�development snapshots URL: http://ftp.FreeBSD.org/pub/FreeBSD/snapshots/ISO-IMAGES/

    Contact: FreeBSD Release Engineering Team <[email protected]>

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

    In early January, the team became aware of several last-minute showstopper issues in FreeBSD�10.0, which led to an extension in the final release builds. FreeBSD�10.0-RELEASE was announced on January 20, two months behind the original schedule.

    The schedule for the FreeBSD�9.3-RELEASE cycle has been written and posted to the website, and the release cycle will begin early May.

    There is ongoing work to integrate support for embedded architectures as part of the release build process. At this time, support exists for a number of ARM kernels, in particular the Raspberry Pi, BeagleBone, and WandBoard.

    This project was sponsored by The FreeBSD Foundation.


    Projects


    Jenkins Continuous Integration for FreeBSD

    Links
    Jenkins CI server in FreeBSD cluster URL: https://jenkins.FreeBSD.org
    Jenkins on FreeBSD project status URL: https://wiki.freebsd.org/Jenkins#Jenkins_for_FreeBSD_status
    Video and slides of March 13, 2014 presentation at Bay Area FreeBSD User Group (BAFUG) URL: https://wiki.freebsd.org/Jenkins#Presentations_and_Working_Groups
    Jenkins, libvirt, and bhyve URL: http://empt1e.blogspot.ru/2014/03/using-jenkins-libvirt-slave-plugin-with.html
    Jenkins Continuous Integration URL: http://jenkins-ci.org
    Ansible URL: http://www.ansible.com

    Contact: Craig Rodrigues <[email protected]>
    Contact: Jenkins Administrators <[email protected]>
    Contact: FreeBSD Testing <[email protected]>

    Jenkins is a framework used by many companies and open source projects for Continuous Integration (CI). CI allows developers to commit code to a Source Code Management (SCM) system such as Subversion, and then have automated programs check out, build, and test the code. Jenkins is implemented in the Java language.

    Ed Maste reviewed some CI work that Craig Rodrigues had done for the FreeNAS project with Jenkins, and encouraged him to set up something similar for the FreeBSD Project. With the help of the FreeBSD Cluster Administration Team, he set up a FreeBSD machine running two bhyve virtual machines, jenkins-9.FreeBSD.org and jenkins-10.FreeBSD.org. He set up software builds of head and several stable branches on these machines. The status of these builds is visible on a web interface accessible at jenkins.FreeBSD.org. When any of the builds fail, emails are sent to freebsd-current or freebsd-stable. Emails are also sent directly to the list of people who recently committed code to Subversion since the last successful build.

    As part of the Jenkins setup, Craig Rodrigues encountered problems with running Java on FreeBSD�9.2 and FreeBSD�10.0. Both problems stemmed from changes to the FreeBSD Virtual Memory (VM) subsystem. On FreeBSD 9.2-RELEASE, running Jenkins under Java would cause the kernel to panic. This was a known problem, and fixed in 9.2.-RELEASE-p3. On FreeBSD 10.0-RELEASE, Java processes would randomly crash. Disabling the vm.pmap.pcid_enabled sysctl(3) variable seemed to fix the problem. In kern/187238, Henrik Gulbrandsen submitted fixes to the FreeBSD VM to address this problem. Konstantin Belousov committed the fixes to head, where they are being tested now.

    During the setup of the bhyve VMs which run Jenkins processes, Craig Rodrigues wrote scripts to start bhyve VMs from the rc.d bootup scripts, which were then published at GitHub.

    On February 19, 2014, Craig Rodrigues notified the FreeBSD developers that Jenkins was running in the FreeBSD cluster, and that they could look at the web interface to see the status of builds.

    On March 13, 2014, Craig Rodrigues gave a presentation of the Jenkins work at the Bay Area FreeBSD User Group (BAFUG) in Mountain View, California, USA. Video of the presentation was recorded and put online by iXsystems.

    Craig Rodrigues assembled a team of volunteers, jenkins-admin, to help maintain jenkins.FreeBSD.org and expand the use of Jenkins CI used in the FreeBSD cluster. jenkins-admin consists of the following people working in the following areas:

    • R. Tyler Croy is both a FreeBSD developer and a Jenkins developer. He will be working on fixing bugs in Jenkins specific to FreeBSD. He is first looking at fixing the libpam4j library which is used by Jenkins to interface with the PAM system for user authentication. The released version of libpam4j does not currently work on FreeBSD.
    • Li-Wen Hsu maintains the devel/jenkins port. He set up a Jenkins build which runs the scan-build static analyzer which is part of LLVM.
    • Steven Kreuzer has experience administering Jenkins systems. He set up several builds on jenkins.FreeBSD.org, including a Jenkins build of the FreeBSD documentation. He is looking into using Ansible for automatic provisioning of VMs running Jenkins in the FreeBSD cluster.
    • Craig Rodrigues will be running a Continuous Testing working group at the FreeBSD Devsummit in Ottawa on May 15, 2014. He will also give a Jenkins presentation on May 17, 2014. He is interested in working with Julio Merino to integrate Jenkins and Kyua. They have exchanged some emails about this on the freebsd-testing list.
    • Steve Wills maintains the devel/jenkins-lts port. He has implemented several builds at jenkins.FreeBSD.org which detect commits to the FreeBSD ports repository, and then build the ports tree using Poudri�re.

    At the end of March, Roman Bogorodskiy reported to jenkins-admin that he has successfully run the Jenkins libvirt plugin with his libvirt modifications to integrate with bhyve. He provided a link to a blog posting where he described his experience.

    This project was sponsored by iXsystems, Inc.

    Open tasks:

    1. Obtain certificates for LDAP and web servers, to replace self-signed certificates.
    2. Set up more Jenkins builds of the FreeBSD base repository on different branches and with different configurations.
    3. Set up more Jenkins builds of the FreeBSD ports repository on different FreeBSD versions.
    4. Integrate with Kyua, so that Jenkins can run Kyua tests and report the results directly in the native Jenkins web UI where test results are reported.
    5. Write scripts which can take a Jenkins build of FreeBSD, and boot the results in a bhyve VM or on real hardware.
    6. Fix libpam4j on FreeBSD.
    7. Continuous Testing working group at Devsummit on May 15, 2014
    8. Jenkins presentation at BSDCan on May 17, 2014

    ZFSguru

    Links
    Home page URL: http://zfsguru.com/

    Contact: Jason Edwards <[email protected]>

    ZFSguru is a multifunctional server appliance with a strong emphasis on storage. It wants to deliver all the great BSD and ZFS technology to a wider audience, while at the same time pleasing more advanced users as well with unique features and customization.

    A vanilla ZFSguru installation comes with only Samba and a web-interface setup, but can be extended easily by installing addons called services to add functionality as desired. This prevents users from running programs they do not need and do not want. Advanced users can still use ZFSguru as they would a normal FreeBSD installation with a 100% ZFS setup (Root-on-ZFS). ZFSguru does not strip away anything, and uses a GENERIC-like kernel with only some additional settings added like InfiniBand networking, Device Polling and AltQ. This means you can use a ZFSguru installation as you would use a FreeBSD installation.

    In the first month of 2014, ZFSguru has released beta9 version of the web interface. This release brings vastly improved support for Samba and NFS configuration. In particular, it adds a convenient drag-and-drop interface for Samba permissions. This allows novice users to configure access to shares in various configurations. It allows both control and usability, with no manual being necessary in order to operate it. This is the ZFSguru style.

    New system versions have been released, based on FreeBSD 9.2, 10.0, and head. The experimental head version has vt(4) and X.org 7.12.4 and the Intel/Radeon KMS graphics drivers. That is, the latest and greatest of FreeBSD graphics development. The ZFSguru project plans to release stable/10 builds in the near future which also have the MFCed patches for vt(4), the KMS-enabled system console with Unicode support. Please see the vt(4) entry for more information.

    Support for ZFS version 5000 is now universal across 9.2, 10.0 and head builds. LZ4 compression is the key feature for ZFS version 5000. Otherwise users are advised to keep their pool versions as is, to be as compatible as you can with as many ZFS platforms as possible. Only upgrade the pool as you desire its functionality, forfeiting the compatibility with older storage platforms.

    Open tasks:

    1. ZFSguru beta10 will increase the compatibility of newly added Samba functionality with non-Gecko browsers. It will also fix some minor bugs as well as speed up some pages by having a redesigned remote database system called GuruDB.
    2. ZFSguru beta11 will add the one major feature still missing in ZFSguru: the Migration Manager. This allows users to maintain a file with all the configuration of their ZFSguru installation. It can be used like a firmware — restoring the machine to the exact state and configuration of the snapshot configuration. It allows users to maintain a backup of their ZFSguru configuration and allows upgrading to a newer ZFSguru system version without any hassle.
    3. Automated system builds should bring more system image releases.
    4. New website with new forum and new login system.
    5. Developer website with GitLab setup, allowing bug reports, code contributions, wiki, and wall messages. Note that GitLab has also been provided as a ZFSguru service, for those interested in trying GitLab.

    Kernel


    ASLR and PIE

    Links
    Blog post with latest status update URL: http://0xfeedface.org/blog/lattera/2014-04-03/awesome-freebsd-aslr-progress
    Shawn's ASLR branch URL: https://github.com/lattera/freebsd/tree/soldierx/lattera/aslr
    Oliv�r's ASLR branch URL: https://github.com/opntr/opBSD/tree/op/stable/10-aslr

    Contact: Shawn Webb <[email protected]>
    Contact: Oliv�r Pint�r <[email protected]>

    Address space layout randomization (ASLR) is a computer security technique involved in protection from buffer overflow attacks. In order to prevent an attacker from reliably jumping to a particular exploited function in memory, ASLR involves randomly arranging the positions of key data areas of a program, including the base of the executable and the positions of the stack, heap, and libraries, in a process' address space.

    We have added ASLR support to all architectures. As the primary developers behind this feature have the most access to amd64, the focus of development is on the amd64 architecture. Other architectures, such as ARM, have known bugs with our current ASLR implementation and we are working hard to fix them. We added support for Position-Independent Executables (PIEs) in a number of applications in base.

    Open tasks:

    1. Shawn has access to a Raspberry Pi (RPI). PIE is 90% broken. Debug and fix major issues on the RPI. The existing NX stack protections are not obeyed on RPI. Properly implemented ASLR requires a NX stack.
    2. Shawn will be receiving a sparc64 box on April 6, 2014. He will test ASLR on sparc64, identifying and fixing any bugs that pop up.
    3. Oliv�r has identified one or more bugs with the Linuxulator. He will be looking into that and fixing those.
    4. Shawn will be cleaning up code and adding support for PIE to more applications in base. He will also add PIE support to the ports framework for general consumption.
    5. Shawn will be giving a presentation regarding ASLR at BSDCan�2014.

    Intel GPU Driver Update

    Contact: Konstantin Belousov <[email protected]>

    The project to update the Intel graphics chipset driver (i915kms) to a recent snapshot of the Linux upstream code continues. Progress was delayed by external circumstances, but it is hoped to reach a useful milestone in the near future.

    This project was sponsored by The FreeBSD Foundation.

    Native iSCSI Stack

    Links
    URL: https://wiki.freebsd.org/Native%20iSCSI%20target

    Contact: Edward Tomasz Napierała <[email protected]>

    The new FreeBSD in-kernel iSCSI stack was functionally complete in FreeBSD 10.0-RELEASE, but ongoing enhancements and bug fixes are being committed to FreeBSD head, with a plan to merge them back to stable/10 in time for FreeBSD 10.1-RELEASE.

    Many issues have been resolved, including very slow operation with data digests enabled, bugs in persistent reservations which impacted Hyper-V Failover Cluster, and a negotiation problem affecting Dell Equallogic users.

    There have also been numerous enhancements, such as support for redirections, which are necessary for some High Availability setups, and the ability to modify session parameters in the iscsictl utility. Previously it was necessary to remove the session and add it again.

    This project was sponsored by The FreeBSD Foundation.

    New Automounter

    Contact: Edward Tomasz Napierała <[email protected]>

    The automount project is nearing the functional prototype stage, and a call for testing is expected in the next month. The userspace portion consists of the automountd(8) daemon, which is designed to be fully compatible with its counterparts in OS X, Solaris, and Linux, and which is nearly complete. Work on the kernel component continues.

    This project was sponsored by The FreeBSD Foundation.

    PCI SR-IOV Infrastructure

    Links
    Work in progress on GitHub URL: https://github.com/rysto32/freebsd/tree/iov_ixgbe

    Contact: Ryan Stone <[email protected]>

    PCI Single Root I/O Virtualization (SR-IOV) is an optional part of the PCIe standard that provides hardware acceleration for the virtualization of PCIe devices. When SR-IOV is in use, a function in a PCI device (known as a Physical Function, or PF) will present multiple Virtual PCI Functions (VF) on the PCI bus. These VFs are fully independent PCI devices that have access to the resources of the PF. For example, on a network interface card, VFs could transmit and receive packets independent of the PF.

    The most obvious use case for SR-IOV is virtualization. A hypervisor like bhyve could instantiate a VF for every VM and use PCI passthrough to assign the VFs to the VMs. This would allow multiple VMs to share access to the PCI device without having to do any expensive communication with the hypervisor, greatly increasing performance of performing I/O from a VM.

    There are two parts to this project. The first is implementing an API in the PCI subsystem for creating VFs and configuring standard PCI features like BARs. The second part is updating individual drivers for PCI devices that support SR-IOV to configure their VFs. For example, a network interface driver will typically have to assign a MAC address to a VF and configure the interface to route packets destined for that MAC address to the VF.

    At this point only SR-IOV support for the ixgbe(4) driver is planned. The PCI subsystem API is designed to be generic and should support SR-IOV on any device, but fairly extensive driver work is necessary to support SR-IOV, which is currently not planned due to lack of time and hardware.

    At present, ixgbe(4) is able to create VFs and the ixgbevf driver is able to pass traffic. There is still a fair amount of work to support VLAN tags, multicast addresses, and other features on the VFs. Also, the VF configuration needs to be better integrated with the PF initialization path to ensure that resets of the PF do not interrupt operation of the VFs.

    This project was sponsored by Sandvine, Inc.

    SDIO Driver

    Links
    SDIO project page on FreeBSD wiki URL: https://wiki.freebsd.org/SDIO
    Source code URL: https://github.com/kibab/freebsd/tree/mmccam

    Contact: Ilya Bakulin <[email protected]>

    SDIO is an interface designed as an extension of the existing SD card standard, allowing connection of different peripherals to the host with the standard SD controller. Peripherals currently sold on the general market include WLAN/BT modules, cameras, fingerprint readers, and barcode scanners. The FreeBSD driver is implemented as an extension to the existing MMC bus, adding a lot of new SDIO-specific bus methods. A prototype of the driver for the Marvell SDIO WLAN/BT (Avastar 88W8787) module is also being developed, using the existing Linux driver as a reference.

    SDIO card detection and initialization already work; most needed bus methods are implemented and tested.

    The WiFi driver is able to load firmware onto the card and initialize it. Migration of the MMC stack to the new locking model is necessary in order to work with SDIO cards effectively. The FreeBSD CAM implementation is believed to be a good choice. There is ongoing work to implement an MMC transport for CAM.

    Open tasks:

    1. SDIO stack: finish CAM migration. The XPT layer is almost ready. What is missing is a SIM module, for which a modified version of the SDHCI controller driver will be used, and a peripheral module, where porting the mmcsd(4) driver is required.
    2. Marvell SDIO WiFi: connect it to the FreeBSD network stack, write the code to implement required functions, such as sending and receiving data, network scanning and so on.

    UEFI Boot

    Links
    Project page on the wiki URL: https://wiki.freebsd.org/UEFI

    Contact: Ed Maste <[email protected]>

    The Unified Extensible Firmware Interface (UEFI) provides boot- and run-time services for x86 computers, and is a replacement for the legacy BIOS. This project will adapt the FreeBSD loader and kernel boot process for compatibility with UEFI firmware, found on contemporary servers, desktops, and laptops.

    Starting with Rui Paulo's i386 EFI loader, Benno Rice developed a working proof-of-concept amd64 loader in 2013 under sponsorship from the FreeBSD Foundation. After refinement, that work has now been merged from the projects/uefi Subversion branch into FreeBSD head. The project includes the infrastructure to build a UEFI-enabled loader, and the kernel-side changes to parse metadata provided by the loader.

    A number of integration tasks remain, with a plan to have UEFI installation and boot support merged to stable/10 in time for FreeBSD 10.1-RELEASE.

    This project was sponsored by The FreeBSD Foundation.

    Open tasks:

    1. Document manual installation, including dual-boot configurations.
    2. Implement chain-loading from UFS/ZFS file systems.
    3. Integrate UEFI configuration with the FreeBSD installer.
    4. Support secure boot.

    Updated vt(4) System Console

    Links
    Project wiki page URL: https://wiki.freebsd.org/Newcons

    Contact: Aleksandr Rybalko <[email protected]>
    Contact: Ed Maste <[email protected]>
    Contact: Ed Schouten <[email protected]>

    vt(4) is a modern replacement for the existing, quite old, virtual terminal emulator called syscons(4). Initially motivated by the lack of Unicode support and infrastructural issues in syscons(4), the project was later expanded to cover the new requirement to support Kernel Mode Setting (KMS).

    The project is now in head, stable/10 and stable/9 branches. Hence, vt(4) can be tested by using the VT kernel configuration (i386 and amd64) or by replacing two lines in the GENERIC kernel configuration file:

    device sc
device vga

    with the following ones:

    device vt
device vt_vga

    Or, to use for UEFI testing, add the following lines instead:

    device vt
device vt_efifb

    Major highlights:

    • Unicode support.
    • Double-width character support for CJK characters.
    • xterm(1)-like terminal emulation.
    • Support for Kernel Mode Setting (KMS) drivers (i915kms, radeonkms).
    • Support for different fonts per terminal window.
    • Simplified drivers.

    Brief status of supported architectures and hardware:

    • amd64 (VGA/i915kms/radeonkms) — works.
    • ARM framebuffer — works.
    • i386 (VGA/i915kms/radeonkms) — works.
    • IA64 — untested.
    • MIPS — untested.
    • PPC and PPC64 — work, but without X.Org yet.
    • SPARC — works on certain hardware (e.g., Ultra 5).
    • vesa(4) — in progress.
    • i386/amd64 nVidia driver — not supported. VGA should be used (VESA planned).
    • Xbox framebuffer driver — will be deleted as unused.

    This project was sponsored by The FreeBSD Foundation.

    Open tasks:

    1. Create sub-directories for vt(4) under /usr/share/ to store key maps and fonts.
    2. Implement the remaining features supported by vidcontrol(1).
    3. Write the vt(4) manual page. (This is in progress.)
    4. Support direct handling of keyboard by the kbd device (without kbdmux(4)).
    5. CJK fonts. (This is in progress).
    6. Address performance issues on some architectures.
    7. Switch to vt(4) by default.

    Architectures


    bhyve

    Links
    bhyve FAQ and Talks URL: http://www.bhyve.org
    Talk: bhyve Past, Present, Future URL: http://www.youtube.com/watch?v=lTOiSyu0-MA

    Contact: Peter Grehan <[email protected]>
    Contact: Neel Natu <[email protected]>
    Contact: John Baldwin <[email protected]>
    Contact: Tycho Nightingale <[email protected]>
    Contact: Allan Jude <[email protected]>

    bhyve is a Type-1 hypervisor that runs on the FreeBSD platform. It currently only runs FreeBSD (9.x or later) and Linux guests; current development efforts aim at widening support for other x86 64-bit operating systems. After a great deal of work by all involved, bhyve was shipped as part of FreeBSD 10.0-RELEASE. Increased interest in bhyve and the first usable versions have provided great feedback and many bug reports.

    A number of important improvements have been made to bhyve this quarter:

    • Optionally ignore accesses to unimplemented MSRs
    • Support soft power-off via the ACPI S5 state for bhyve guests
    • Graceful shutdown via ACPI on SIGTERM
    • Fix an issue with virtio-blk devices on Linux guests with more than 4GB of RAM
    • Increase the block-layer backend maximum requests to match AHCI command queue depth
    • Add SMBIOS support
    • Improve support for nmdm, opening the tty non-blocking
    • Add HPET device emulation
    • Implement the Virtual Interrupt Delivery and Posted Interrupt Processing VT-x features on newer Intel CPUs
    • Add support for booting FreeBSD/i386 guests
    • Add virtualized XSAVE support for features like AVX
    • Add Support for booting from ZFS with bhyveload

    Open tasks:

    1. Improve documentation.
    2. Write Handbook chapter for bhyve.
    3. Merge fixes and features back to stable/10.
    4. Support for booting with UEFI instead of userspace loaders.
    5. CSM BIOS boot support for FreeBSD (which has no UEFI support currently).
    6. Add support for virtio-scsi.
    7. Improve virtio-net, add offload features, support multiple queues.
    8. Implement Intel 82580 and e1000 NIC emulation.
    9. Netmap support.
    10. Flexible networking backend: wanproxy, vhost-net.
    11. Improve resource accounting.
    12. Move to a single process model, instead of bhyveload and bhyve.
    13. Support running bhyve as non-root.
    14. Add filters for popular VM file formats (VMDK, VHD, QCOW2).
    15. Implement an abstraction layer for video (no X11 or SDL in base system).
    16. Support for VNC as a video output.
    17. Implement USB and Sound.
    18. Suspend/resume support.
    19. Live Migration.
    20. Nested VT-x support (bhyve in bhyve).
    21. Support for other architectures (ARM, MIPS, PPC).

    FreeBSD Host Support for OpenStack and OpenContrail

    Links
    URL: http://www.openstack.org
    URL: http://www.opencontrail.org
    URL: https://github.com/Semihalf/openstack-devstack
    URL: https://github.com/Semihalf/openstack-nova
    URL: https://github.com/Semihalf/contrail-vrouter
    URL: https://blueprints.launchpad.net/nova/+spec/freebsd-compute-node

    Contact: Grzegorz Bernacki <[email protected]>
    Contact: Michał Dubiel <[email protected]>
    Contact: Dominik Ermel <[email protected]>
    Contact: Rafał Jaworowski <[email protected]>

    OpenStack is a cloud operating system that controls large pools of compute, storage, and networking resources in a data center. OpenContrail is a network virtualization (SDN) solution comprising a network controller, virtual router, and analytics engine, which can be integrated with cloud orchestration systems like OpenStack or CloudStack.

    The goal of this work is to make FreeBSD a fully supported compute host for OpenStack using OpenContrail virtualized networking. The main areas of development are:

    • Libvirt hypervisor driver for bhyve.
    • Support for bhyve (via the libvirt compute driver) and the FreeBSD platform in overall in nova-compute.
    • Port OpenContrail vRouter (forwarding plane kernel module) to FreeBSD.
    • Port OpenContrail Agent (network controller node) to FreeBSD.
    • Integration, performance optimization.

    The current state of development allows for a working demo of OpenStack with compute node component running on a FreeBSD host:

    • The native bhyve hypervisor is driven by a nova-compute component for spawning guest instances using libvirt and a nova-network component for providing simple networking using bridges between guest VMs.
    • QEMU might also be used instead of bhyve this way.
    • The main goal on the networking side is to use the OpenContrail solution, compliant with the modern OpenStack networking API ("neutron").

    Also, an initial port of the OpenContrail vRouter kernel module has been completed. It successfully handles all networking on the host.

    This project was sponsored by Juniper Networks.

    FreeBSD on Chromebook

    Links
    Manual URL: https://wiki.freebsd.org/FreeBSD/arm/Chromebook

    Contact: Ruslan Bukin <[email protected]>

    One model of Chromebook is an ARMv7 Cortex-A15 personal computer powered by a Samsung Exynos 5 Dual System-on-Chip. As of the current status of this project, such laptops can be booted with FreeBSD from USB flash — it works stably (including SMP) and it can build third-party applications. The display and keyboard work.

    Thanks to Peter Grehan for providing hardware.

    Open tasks:

    1. Implement keyboard polling mode.
    2. Add support for the upcoming second generation of Chromebook.
    3. Write SD, SATA drivers.

    FreeBSD/arm64

    Links
    Project branch in the Subversion repository URL: http://svnweb.freebsd.org/base/projects/arm64/
    GitHub repository URL: https://github.com/zxombie/aarch64-freebsd-sandbox

    Contact: Andrew Turner <[email protected]>

    Arm64 is the name of the in-progress port of FreeBSD to the ARMv8 CPU when it is in AArch64 mode. Until recently, all ARM CPU designs were 32-bit only. With the introduction of the ARMv8 architecture, ARM has added a new 64-bit mode. This new mode has been named AArch64.

    Progress has been good on getting FreeBSD to build and run on the ARM Foundation model. FreeBSD is able to be built for this architecture, however, it requires a number of external tools including objdump(1) and ld(1). These tools are provided by an external copy of binutils until replacements can be written.

    FreeBSD will run the early boot on the Foundation model. The loader has been ported to the AArch64 UEFI environment and can load and run the kernel. The kernel is able to create the initial page tables to be able to run from virtual memory. It can then execute C code to parse the memory map provided by the loader. This is as far as the kernel currently boots.

    This work is now happening in the FreeBSD Subversion repository in a project branch, see the links.

    Open tasks:

    1. Implement an initial pmap(9) layer.
    2. Write the missing machine-dependent code.
    3. Test on real hardware.

    FreeBSD/armv6hf

    Contact: Andrew Turner <[email protected]>

    FreeBSD has been updated to allow it to use the VFP variant of the ARM EABI ABI. The VFP unit is the ARM hardware to perform floating-point operations. This changes the ABI to improve the performance of code that uses floating-point operations. By default, FreeBSD already uses the ARM EABI on all releases from 10.0.

    This is important for FreeBSD/arm users running code with floating-point operations on ARMv6 or ARMv7 SoC systems. It removes the need for the slow software floating-point support in libc. This is mostly compatible with the existing ABI, with the exception of how floating-point values are passed into functions. Because no floating-point values are passed to the kernel, the armv6 and armv6hf kernels will work with either userland.

    As part of this change, some support functions have been updated to use the VFP unit when available. The existing armv6 target architecture will be kept for cases where the SoC lacks a VFP unit, or existing binaries that are incompatible with the new ABI.

    Open tasks:

    1. Testing.
    2. More testing.

    SMP on Multi-Core ARM Systems

    Links
    Announcement URL: http://lists.freebsd.org/pipermail/freebsd-arm/2014-April/007886.html

    Contact: Ian Lepore <[email protected]>
    Contact: Olivier Houchard <[email protected]>
    Contact: Wojciech Macek <[email protected]>

    FreeBSD now supports Symmetrical MultiProcessing (SMP) on a variety of ARM multi-core systems. The effort to bring SMP to ARM has been underway for quite some time, but a major push by the FreeBSD ARM developer community over the past two months has resulted in robust production-ready SMP support.

    An ever-growing number of ARM-based development boards and small low-power computer systems are available with multi-core processors. FreeBSD is now able to make good use of all that computing power, making such systems more attractive to both end users and vendors looking to create products based on similar designs.

    As of r264138 in FreeBSD head, SMP is now enabled by default in the configuration files for all currently-supported systems that have multi-core processors. This includes systems based on the following processor families:

    • Allwinner A20
    • Freescale i.MX6
    • Marvell Armada XP
    • Samsung Exynos 5
    • Texas Instruments OMAP4

    We plan to merge this work to stable/10 in time for 10.1-RELEASE.

    This project was sponsored by Microsemi, Inc., and Semihalf sp.j.


    Userland Programs


    auditdistd(8)

    Contact: Pawel Jakub Dawidek <[email protected]>

    The auditdistd(8) daemon is responsible for distributing audit trail files over TCP/IP networks securely and reliably.

    The daemon now supports client-side certificates, which can be used to automatically configure the receiver side — the directory name for received trail files is determined based on the commonName field in client's certificate. There is no need any more to add every sender to the receiver's configuration file.

    The sender's functionality was extended to allow sending audit trail files to multiple receivers.

    Complete Public Key Infrastructure (PKI) support is now implemented, including full certificate chain verification, Certificate Revocation Lists (CRL) verification at every level and support for multiple Certificate Authority (CA) certificates.

    This project was sponsored by The FreeBSD Foundation.

    External Toolchain Improvements

    Links
    Brooks Davis' XCC work URL: https://wiki.freebsd.org/ExternalToolchain

    Contact: Warner Losh <[email protected]>

    Building on the work that Brooks Davis did to enable external Clang toolchains, this project hopes to generalize that to GCC, as well as support different versions of these compilers simultaneously for the FreeBSD base system and the kernel. We also hope get to the point that a port can be cross-compiled entirely from scratch with no initial binary artifacts.

    Open tasks:

    1. Setup Subversion project repository.
    2. Fix issues with differences of interpretation of the -B argument between GCC and Clang.
    3. Support building the entire tree based only on xdev-built compilers.
    4. Support building the entire tree based only on ports-built GCC compilers.
    5. Support full bootstrapping of FreeBSD to new platforms.

    Forward Port FreeBSD GCC

    Contact: Warner Losh <[email protected]>

    Not all of the FreeBSD changes to GCC have been reflected upstream. A large amount of the platform support as well as a couple of minor improvements like the kernel formatting checker need to be forward ported (and if possible, moved upstream into GCC).

    We will be targeting the FreeBSD ports tree lang/gcc* ports for these efforts to (optionally) include them in these builds. Some variation from normal builds may be required due to bootstrapping issues when combined with the external toolchain enhancements project.

    FreeBSD Test Suite

    Links
    Project page URL: http://wiki.FreeBSD.org/TestSuite
    Testing cluster URL: http://kyua1.nyi.FreeBSD.org/
    Roadmap for the project URL: http://julipedia.meroh.net/2014/01/freebsd-test-suite-goals-and-planning.html
    AsiaBSDCon 2014 tutorial materials URL: https://drive.google.com/a/meroh.net/#folders/0B08g-X1kPkSYNmlEdTB5RjlFbkk

    Contact: Julio Merino <[email protected]>

    The FreeBSD Test Suite project aims to equip FreeBSD with a comprehensive collection of tests that are easy to run out of the box and during the development of the system. The test suite is installed into /usr/tests/ and the kyua(1) command-line tool (devel/kyua in the Ports Collection) is used to run them. See the project page for more details.

    Since the last status report, we have been hard at work polishing the framework in many different areas. The highlights are:

    • A roadmap for the project has been prepared and published, see links.
    • Many tests have been added to the test suite thanks to the work of various developers and, in particular, a good bunch of old tests from src/tools/regression/ have been incorporated into the new test suite. As of this writing, there are 509 test cases continuously running.
    • The testing infrastructure in the stable/10 branch has been synced to head. It should now be possible to seamlessly MFC changes to the stable branch along with their tests, if any.
    • The testing cluster, which only issued amd64 builds, has been extended to perform i386 builds as well. Additionally, a canary machine has been put in place so that changes to the cluster configuration can be properly validated before deployment.
    • A tutorial on Kyua and the FreeBSD Test Suite was given at AsiaBSDCon 2014. The tutorial materials are available for public consumption, please consult the links.
    • Both Kyua's and ATF's upstream sites have been moved to GitHub, mostly due to the discontinuation of file downloads in Google Code.

    Open tasks:

    1. Enable the build of the test suite by default.
    2. Add alerting for failed or missing test runs from the testing cluster.
    3. Add bhyve support to the testing cluster for faster turnaround times.
    4. Simplify and improve Kyua HTML reports. In particular, reports will be coalesced into single HTML files for easier management and will include more useful details for debugging. Such details are the revision at which the system was built, the date and duration of the whole run, or the list of installed packages, to mention a few examples.
    5. Add JUnit XML output to Kyua for better integration with Jenkins. This work is actively ongoing and should be ready for prime time at BSDCan�2014.

    LLDB Debugger Port

    Links
    URL: https://wiki.FreeBSD.org/lldb

    Contact: Ed Maste <[email protected]>

    LLDB is the debugger project associated with Clang/LLVM. It supports the Mac OS X, Linux, and FreeBSD platforms, with ongoing work on Windows. It builds on existing components in the larger LLVM project, for example using Clang's expression parser and LLVM's disassembler.

    The majority of work since the last status update has been on bugfixes and implementation of the remaining functionality missing on FreeBSD. Most of these improvements are now in the LLDB snapshot in the base system, which has been updated to upstream Subversion revision r202189. Some highlights of the new update include:

    • Improvements to the remote GDB protocol client.
    • Bug fixes for big-endian targets.
    • Initial support for libdispatch (GCD) queues in the debuggee.
    • Add "step-avoid-libraries" setting.
    • IO subsystem improvements (including initial work on a curses GUI).
    • Support hardware watchpoints.
    • Improved unwinding through hand-written assembly functions.
    • Handle DW_TAG_unspecified_parameters for variadic functions.
    • Fix Ctrl+C interrupting a running inferior process.
    • Various bug fixes for memory leaks, LLDB segfaults, the C++ demangler, ELF core files, DWARF debug info, and others.

    LLDB is currently not yet built by default and may be enabled by adding WITH_LLDB= to src.conf(5). A port will be made available for those who wish to track ongoing development more closely.

    This project was sponsored by DARP/AFRL, SRI International, and University of Cambridge.

    Open tasks:

    1. Add support for remote debugging (gdbserver-compatible debugserver).
    2. Add support for local and core file kernel debugging.
    3. Implement, fix or test support on all non-amd64 architectures.
    4. Verify cross-debugging.
    5. Investigate and fix test suite failures.
    6. Package LLDB as a port.
    7. Enable by default in the base system for working architectures.

    Ports


    Chromium

    Links
    Chromium website URL: http://www.chromium.org/Home
    Development repository on GitHub URL: https://github.com/gliaskos/freebsd-chromium
    Chromium on FreeBSD wiki URL: https://wiki.freebsd.org/Chromium

    Contact: Chromium on FreeBSD Team <[email protected]>

    Chromium is the open source web browser project from which Google Chrome draws its source code. The browsers share the majority of code and features, though there are some minor differences in features and they have different licensing. Over the last four years, the Chromium team has been busy with porting Chromium to FreeBSD. This involves patching the browser so that it runs on FreeBSD, tracking and documenting security updates, and merging patches back upstream.

    While there are already several browsers available for FreeBSD, advantages of Chromium are:

    • Quick response from upstream to security issues, resulting in approximately bi-weekly updates.
    • A testbed for security features of FreeBSD, like Capsicum. While support for this capability and sandbox framework is currently not included in the browser, a proof-of-concept implementation for an early version of Chromium was realized within a single weekend.

    George Liaskos and Ren� Ladan are currently busy with submitting the remaining patches specific to FreeBSD back upstream. Apart from making future updates easier, it sometimes also improves the overall code quality.

    Jonathan Anderson recently updated the Capsicum patches for Chromium and is talking to upstream about them.

    Open tasks:

    1. Advocate FreeBSD. While patches are getting accepted by both humans and bots, it is not an official platform so attitude varies from developer to developer. While Ren� Ladan thinks it is a bit early, it might be fruitful to investigate what is required to make FreeBSD (and possibly OpenBSD) an official platform in terms of both hardware and procedures.
    2. If you feel comfortable with large source trees, you can try to build the Git version of Chromium on FreeBSD. If you are also comfortable with signing Google's Contributor License Agreement, you can join in testing and submitting patches upstream.

    FreeBSD Ada Ports

    Links
    URL: http://www.dragonlace.net
    SPARK 2014 URL: http://www.spark-2014.org/about/

    Contact: John Marino <[email protected]>

    Ada is a structured, statically typed, imperative, wide-spectrum, and object-oriented high-level computer programming language, extended from Pascal and other languages, originally targeted at embedded and real-time systems. The number of Ada ports in the collection has grown significantly since the last report six months ago. There are almost 50 Ada-related ports now, with new ones getting added all the time.

    The previous plan was to move from the GCC 4.7-based GNAT compiler to a GCC 4.8-based one, but finally GCC 4.8 was skipped and now a GCC 4.9-based GNAT is the standard Ada compiler, which fully supports the new ISO standard, Ada 2012. Moving to a newer compiler allowed several important ports like PolyOrb and GPRBuild to be upgraded to the latest available versions. In fact, almost every Ada port is currently at its most recent upstream version.

    For non-Windows-based Ada development, FreeBSD and DragonFly are now undisputed as the go-to platforms. The other candidates are Debian and Fedora, but there are few Ada softwares on those platforms that are not also in the FreeBSD ports tree, and the FreeBSD versions are much newer. The Ports Collection also features software not found anywhere else such as the USAFA's Ironsides DNS server, libsparkcrypto, matreshka, GNATDroid (Android cross-compiler) and several developer libraries.

    A desired addition to the Ada ports will be SPARK 2014 (see links), which should cement FreeBSD as an option for professional, safety-critical application development. This package should have its first release by early summer.

    GCC in the Ports Collection

    Links
    Upstream GCC URL: http://gcc.gnu.org

    Contact: Gerald Pfeifer <[email protected]>

    While the age old version of the GNU Compiler Collection (GCC) in the base system is on its way out with FreeBSD�10 and later, there are many users who want—and some platforms which need—to use GCC.

    For that purpose there are various versions of GCC in the ports tree, including lang/gcc46, lang/gcc47, lang/gcc48 and lang/gcc49 which track upstream snapshots of the respective release branches, and more importantly lang/gcc which serves as the canonical version of GCC and is the default when a port requests USE_GCC=yes as well as for some cases of USES=compiler.

    With a lot of help from Christoph Moench-Tegeder who fixed many ports and made a fair number respect CXXFLAGS, LDFLAGS and friends, we managed to update the canonical version from GCC 4.6.4 to GCC 4.7.3. Many of Christoph's fixes also benefit Clang and other modern compilers.

    For users of lang/gcc, this upgrade proved very smooth, and we generally recommend using this port over version specific ones.

    After ten years of service lang/gcc34 retired, as did lang/gcc44 after half that timespan.

    On a related note, with the help of John Marino, the license of the GCC ports now properly reflects the combination of GPLv3 for the compiler itself and GPLv3 with GCC Runtime Library Exception for the runtime. The latter is the key in making it possible to use GCC for building and distributing non-free software.

    Open tasks:

    1. Move lang/gcc from GCC 4.7 to GCC 4.8.

    GNOME/FreeBSD

    Links
    GNOME FreeBSD page URL: http://www.freebsd.org/gnome
    JHbuild info and results URL: https://wiki.gnome.org/Projects/Jhbuild/FreeBSD
    MATE staging repository (might break) URL: https://github.com/jlmess77/mate-ports
    GNOME staging repository (might break) URL: http://marcuscom.com/downloads/marcusmerge

    Contact: FreeBSD GNOME Team <[email protected]>

    GNOME is a desktop environment and graphical user interface that runs on top of a computer operating system. GNOME is part of the GNU Project and can be used with various Unix-like operating systems, including FreeBSD.

    Preparations for merging GNOME�3 are moving forward. The work on the documentation is falling behind a bit, but we got some solid feedback on the rough work to keep this moving forward as well. In the meantime, deprecation of ports that need the old GNOME�2 desktop ports has begun. These ports will break when the GNOME desktop components are updated to the GNOME�3 version.

    Thanks to a combined effort by Ryan Lortie (GNOME developer), Ting-Wei Lan (upstream contributor), and Koop Mast, we now have a FreeBSD-powered JHbuild tinderbox. JHbuild is a build system that allows building GNOME upstream code. Twice a day, it will attempt to build Gnome components from a specific branch, usually the git master branch, to catch compile issues. A positive side effect is that it lets upstream know GNOME still lives on non-Linux systems. It also exposes the GNOME code base to the Clang compiler and libc++. Since the start of this project over a hundred issues have been fixed.

    Gustau Perez has stepped up and put together a port set in the ports-experimental tree of our development repository with GNOME 3.12. It was decided to polish GNOME 3.12. It will be merged when the preparation work has (mostly) finished, and we are happy with the stability of GNOME 3.12.

    Gustau Perez also ported Cinnamon 2.0 to FreeBSD. It will appear in the Ports Collection after GNOME�3 has been merged.

    MATE 1.8 was released at the beginning of April, Eric Turgeon of GhostBSD had volunteered to do that update for FreeBSD. Note that this update is still based on GTK+, version 2. The GTK+�3-based MATE is on the roadmap for 1.10.

    Open tasks:

    1. Finish the work needed to be done before GNOME�3 can be merged at all. Documentation work, port deprecation, and so on.
    2. Finish porting of MATE 1.8.
    3. Update Cairo to 1.12 in coordination with the Graphics Team.

    KDE/FreeBSD

    Links
    KDE/FreeBSD Home Page URL: http://FreeBSD.kde.org
    area51 URL: http://FreeBSD.kde.org/area51.php
    PortScout Status URL: http://portscout.freebsd.org/[email protected]

    Contact: KDE/FreeBSD Team <[email protected]>

    KDE is an international free software community producing an integrated set of cross-platform applications designed to run on Linux, FreeBSD, Solaris, Microsoft Windows, and OS X systems. The KDE/FreeBSD Team have continued to improve the experience of KDE software and Qt under FreeBSD.

    During this quarter, the team has kept most of the KDE and Qt ports up-to-date, working on the following releases:

    • KDE SC: 4.12.2, 4.12.3, and 4.12.4; Workspace: 4.11.6, 4.11.7, and 4.11.8
    • Qt: 5.2.1
    • KDevelop: 4.6.0
    • Digikam (and KIPI-plugins): 3.5.0

    As a result — according to PortScout — kde@ has 526 ports (up from 464), of which 98.86% are up-to-date (up from 88.15%). iXsystems continues to provide a machine for the team to build packages and to test updates. They have been providing the KDE/FreeBSD team with support for quite a long time and we are very grateful for that.

    A major change has been the deprecation of the KDE3 ports and the move of the KDE4_PREFIX to LOCALBASE. Also, work on Qt5 continues to maturity. Raphael Kubo da Costa has been working with upstream to ensure Baloo (Nepomuk successor in KDE SC 4.13) compiles and runs on non-Linux systems. His work not only benefits FreeBSD but other BSDs and OS X.

    As usual, the team is always looking for more testers and porters, so please contact us and visit our home page (see links). It would be especially useful to have more helping hands on tasks such as getting rid of the dependency on the defunct HAL project and providing integration with KDE's Bluedevil Bluetooth interface.

    This project was sponsored by iXsystems, Inc.

    Open tasks:

    1. Update out-of-date ports, see PortScout for a list.
    2. Work on Qt 5.
    3. Make sure the whole KDE stack (including Qt) builds and works correctly with Clang and libc++.
    4. Remove the dependency on HAL.

    libvirt/bhyve Support

    Links
    bhyve Driver URL: http://libvirt.org/drvbhyve.html
    libvirt Home Page URL: http://libvirt.org/
    Developer Blog URL: http://empt1e.blogspot.ru/search/label/libvirt

    Contact: Roman Bogorodskiy <[email protected]>

    Libvirt is a virtualization library providing a common API for various hypervisors (Qemu/KVM, Xen, LXC, and others), and also a popular library used by a number of projects. Libvirt 1.2.2, released on March, 2014, was the first release to include bhyve support. Enabling bhyve support allows consumers to use bhyve in libvirt-ready applications without major efforts.

    Currently, libvirt supports almost all essential features of bhyve, such as Virtual Machine lifecycle (start, stop), bridged networking, and virtio/SATA driver support. The work continues to implement more API calls and to cover more of features offered by bhyve.

    Open tasks:

    1. FreeBSD port of netcf is needed for adding interface driver support to libvirt.

    OpenAFS on FreeBSD

    Links
    OpenAFS homepage URL: http://openafs.org

    Contact: Benjamin Kaduk <[email protected]>

    AFS is a distributed network filesystem that originated from the Andrew Project at Carnegie-Mellon University. OpenAFS is an open-source implementation of the AFS protocol derived from IBM AFS, which was released under the IBM Public License. OpenAFS on FreeBSD (the net/openafs port) is suitable for light use, but is not yet production ready.

    We got a chance to pick up this porting project after some hiatus. Recent work focused on investigating the bugs preventing the use of a disk cache for caching file data. An internal "lookupname" abstraction was intended to return an unlocked, referenced vnode, but instead returned a locked, referenced vnode, leading to various failure modes depending on the number of kernel debugging options enabled.

    Open tasks:

    1. Track down an issue involving incorrect reference counts on the AFS root vnode that cause warnings on shutdown.
    2. Audit the locking in all the vnode operations code — it is expected that there remain some incorrectly locked areas, though none that present visible issues under light load.

    The Graphics Stack on FreeBSD

    Links
    Graphics stack roadmap and supported hardware matrix URL: https://wiki.freebsd.org/Graphics
    WITH_NEW_XORG status URL: https://wiki.freebsd.org/Graphics/WITH_NEW_XORG
    Ports-related development repository URL: http://trillian.chruetertee.ch/ports/browser/trunk

    Contact: FreeBSD Graphics Team <[email protected]>

    On the kernel side, the Radeon KMS driver was merged in stable/9 and will be available in FreeBSD 9.3-RELEASE. Now both the 9.x and 10.x branches share the same support for Intel and AMD GPUs.

    The next big tasks are the updates of the DRM generic code and the i915 driver. Both are making good progress and the DRM update should hopefully be ready for wider testing during April. An update of the Radeon driver is on the to-do list, but nothing is scheduled yet.

    On the ports tree and packages side, the update to Cairo 1.12 mentioned in the last quarterly report is ready to be committed, as people who tested it either reported improvements or no regressions. As a reminder, the switch from Cairo 1.10 to 1.12 causes display artifacts with xf86-video-intel 2.7.1, but fixes similar problems with other hardware/driver combinations. Furthermore, Cairo 1.12 is required by Pango 1.36.0, GTK+ 3.10 and Firefox 27.0. A Heads up mail will be posted to the freebsd-x11 mailing-list when this update goes live.

    In the graphics stack's ports development tree, new Mesa ports are being worked on. Those ports are required to support GLAMOR (the GL-based 2D acceleration library used by Radeon HD 7000+ cards for instance) and OpenCL (using the GPU to perform non-graphical calculations). We were able to execute some "Hello World" OpenCL programs and play with OpenCL in darktable, but there are some compatibility issues between Clover (Mesa's libOpenCL implementation) and Clang/libc++.

    We are preparing an alternate pkg(8) repository with packages built with WITH_NEW_XORG. The goal is to ease the usage of the KMS drivers and move forward with the graphics stack updates. The main pkg(8) repository will still use the default setting (WITH_NEW_XORG set on head, but not on the stable branches).

    This will pave the way to the deprecation ofWITH_NEW_XORG and the removal of the older stack. The current plan is to do this after 10.0-RELEASE End-of-Life, scheduled on January 31st, 2015. By that time, the only supported releases will be 8.4-RELEASE, 9.3-RELEASE and 10.1-RELEASE. FreeBSD 9.3 and 10.1 will be fully equipped to work with the newer stack. Unfortunately, FreeBSD 8.x misses the required kernel DRM infrastructure: supporting X.Org here cripples progress on the graphics stack and, once WITH_NEW_XORG is gone, we will not support 8.x as a desktop any more. Therefore, please upgrade to 9.3 or 10.1 when they are available.

    Open tasks:

    1. See the Graphics and WITH_NEW_XORG wiki pages for up-to-date information.

    Using CentOS 6.5 as Linux Base

    Links
    Work in Progress URL: http://github.com/xmj/linux-ports
    ports/187786 URL: http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/187786

    Contact: Johannes Meixner <[email protected]>

    The Linux emulation layer relies on a Linux base distribution along with Linux ports of relevant non-base software. Fedora 10 was imported in 2006, and it shows — current Linux software like Skype 4, Sublime Text 2, or even modern games fail to run with the provided libraries.

    CentOS 6.5 was released in December 2013 and will be supported until 2017, making it an ideal basis for an update to the ports infrastructure. Built upon the work of Carlos Jacobo Puga Medina, all ports using Linux have been updated to work with either Fedora 10 or CentOS 6.5.

    The goal of this project is to make CentOS 6.5 the default Linux distribution, so that FreeBSD users can enjoy running modern Linux binaries without having to resort to virtualization � la VirtualBox, or even dual-booting.

    This project was sponsored by Goldener Grund O�.

    Open tasks:

    1. Clean up Mk/bsd.linux-*.mk and fix errors detected in ports/187786.
    2. Revert making c6 the default (in the git repository).
    3. Testing.
    4. Review patches and import into the ports tree (any help appreciated).
    5. Make c6 the default (after sufficient testing) within the ports tree.

    Wine/FreeBSD

    Links
    Wine Wiki Page URL: http://wiki.FreeBSD.org/Wine
    Wine on amd64 Wiki Page URL: http://wiki.FreeBSD.org/i386-Wine
    Wine Home Page URL: http://www.winehq.org/

    Contact: Gerald Pfeifer <[email protected]>
    Contact: David Naylor <[email protected]>

    Wine is a free and open source software application that aims to allow applications designed for Microsoft Windows to run on Unix-like operating systems, such as FreeBSD. The Wine project has been in maintenance mode this quarter and has updated the ports for the following versions:

    • Stable releases: 1.6.2
    • Development releases: 1.7.9 through 1.7.15

    The ports have packages built for amd64, available through the ports emulators/i386-wine and emulators/i386-wine-devel.

    Open tasks:

    1. See the Open Tasks and Known Problems sections on the Wine wiki page.
    2. FreeBSD/amd64 integration, consult the i386-Wine wiki page for the details.
    3. Port WoW64 (supporting Windows 32-bit and 64-bit from the same port) and Wine64.

    Xfce/FreeBSD

    Links
    URL: https://wiki.freebsd.org/Xfce
    Development repository URL: https://svn.redports.org/olivierd/xfce4/
    URL: https://people.freebsd.org/~olivierd/xfce-core-unstable.html
    ports/183690 URL: http://www.freebsd.org/cgi/query-pr.cgi?pr=183690

    Contact: FreeBSD Xfce Team <[email protected]>

    Xfce is a free software desktop environment for Unix and Unix-like platforms, such as FreeBSD. It aims to be fast and lightweight, while still being visually appealing and easy to use. The Xfce team continues to keep each piece of the Xfce Desktop up to date.

    The latest commits concerned:

    • Applications:
      • Midori (0.5.7)
      • xfburn (0.5.0)
      • xfce4-parole (0.5.4)
      • xfce4-taskmanager (1.0.1)
      • xfce4-tumbler (0.1.30)
    • Panel plugins:
      • xfce4-clipman-plugin (1.2.5)
      • xfce4-equake-plugin (1.3.4)
      • xfce4-wavelan-plugin (0.5.11)
      • xfce4-whiskermenu-plugin (1.3.2)

    We also follow development of core components (available in your repository). See the links for documentation on how to upgrade those libraries.

    • garcon (0.3.0)
    • libxfce4menu (4.11.1)
    • libxfce4util (4.11.0)
    • xfce4-appfinder (4.11.0)
    • xfce4-desktop (4.11.4)
    • xfce4-dev-tools (4.11.0)
    • xfce4-panel (4.11.0)
    • xfce4-parole (0.6.0)
    • xfce4-settings (4.11.2)
    • xfce4-session (4.11.0)
    • xfce4-wm (4.11.1)
    • xfce4-xkb-plugin (0.7.0)

    Open tasks:

    1. Add support of DragonFly for xfce4-taskmanger.
    2. Finish replacing Tango icon theme with GNOME, in order to close ports/183690 (see links, Midori remains to be fixed).

    Documentation


    ZFS Chapter of the Handbook

    Links
    Preview ZFS Handbook URL: http://www.allanjude.com/zfs_handbook/zfs.html
    Slides from AsiaBSDCon 2014 URL: http://www.allanjude.com/talks/AsiaBSDCon_2014_-_WIP_-_ZFS_Handbook.pdf

    Contact: Allan Jude <[email protected]>
    Contact: Benedict Reuschling <[email protected]>
    Contact: Warren Block <[email protected]>

    ZFS is one of the premier features of FreeBSD. The current documentation in the Handbook and elsewhere online is severely lacking. Much of the original documentation from Sun and Oracle has disappeared, moved, or is about the proprietary version of ZFS.

    New users have many questions about ZFS and yet there exists a great deal more bad advice about ZFS than proper documentation. The current ZFS chapter of the FreeBSD Handbook starts off with the required steps to configure an i386 machine to run ZFS. This is more likely to scare off a new user than to educate them about how to properly use ZFS.

    At BSDCan�2013, the process of writing an entirely new chapter of the Handbook on ZFS was started. Currently this chapter consists of approximately 16,000 words covering all subcommands of the zpool(8) and zfs(8) utilities, delegation, tuning and a section devoted to definitions and explanations of the terms and features of ZFS.

    The remaining section is the FAQ, to help users address the most common problems they might run into with ZFS. It would be useful to hear experiences, questions, misconceptions, gotchas, stumbling blocks, and suggestions for the FAQ section from other users. Also, it would be good to have a use cases section that highlights some of the cases where ZFS provides advantages over traditional file systems.

    Please send suggestions to the freebsd-doc mailing list.

    This project was sponsored by ScaleEngine, Inc.

    Open tasks:

    1. Technical review by Matt Ahrens (co-creator of ZFS).
    2. Improve delegation section.
    3. Improve tuning section, add new sysctls added in head.
    4. Add section on jails and the jailed property.
    5. Add FAQ section.
    6. Add Use Cases section.
    7. General editing and review.

    Miscellaneous


    FreeBSD Participating in Summer of Code 2014

    Links
    URL: http://gsoc.FreeBSD.org
    URL: https://wiki.freebsd.org/SummerOfCode2014

    Contact: Gavin Atkinson <[email protected]>
    Contact: Glen Barber <[email protected]>
    Contact: Wojciech Koszek <[email protected]>

    FreeBSD is pleased to have been accepted as a participating organization in Google's Summer of Code 2014. This will be the tenth time we have participated in the program, having been selected to participate every year since its introduction.

    This year, the administrators made a special attempt to spread the word about Summer of Code around universities, including making contact with around 350 mainly Polish, British, African and American universities to advertise the Summer of Code program, with a particular focus on FreeBSD's participation. We made contact with both technical departments and student societies. Posters were produced in several languages, and FreeBSD committers and users were encouraged to distribute these posters around their local universities.

    FreeBSD received a total of 39 proposals from students, and were subsequently granted 15 slots from Google. We are now facing the unpleasant challenge of trying to decide which of the 39 proposals to select, taking into account the quality, desirability and feasibility of each proposal, as well as ensuring we will be able to provide an excellent mentoring experience to each selected student. All mentors have volunteered to mentor, and we pair students with mentors primarily based on the prospective mentor's areas of expertise, interest in the project, also taking into account the desire to pair students up with mentors in similar time zones in order to improve the student experience. The final list of accepted students is expected to be announced on the 21st April.

    The FreeBSD Foundation

    Links
    URL: http://www.FreeBSDFoundation.org/
    FreeBSD Journal URL: http://freebsdjournal.com/

    Contact: Deb Goodkin <[email protected]>

    The FreeBSD Foundation is a 501(c)(3) non-profit organization dedicated to supporting and promoting the FreeBSD Project and community worldwide. Most of the funding is used to support FreeBSD development projects, conferences and developer summits, purchase equipment to grow and improve the FreeBSD infrastructure, and provide legal support for the Project.

    We published the first issue of the FreeBSD Journal, our new on-line FreeBSD magazine. The positive feedback from both the FreeBSD and outside communities has been incredible. This quarter we began work on articles and promotion for the second issue. We also started working on a dynamic version of the magazine that can be read in many web browsers including those that run on FreeBSD.

    This year we are earmarking more funding towards FreeBSD advocacy and education. You will see more literature, white papers, articles, and so on to help promote FreeBSD.

    The Foundation held a board meeting in Berkeley, California, in January. We discussed longer term strategy and planning for the year. We put together our 2014 budget with a plan of raising at least $1,000,000 and spending $900,000.

    Two Foundation funded projects were completed. The first, co-sponsored by Google, integrated the Casper daemon into FreeBSD. The second was auditdistd(8) improvements for the FreeBSD cluster.

    Work continued on these Foundation-sponsored projects: Intel graphics driver update by Konstantin Belousov, UEFI boot support for amd64 by Ed Maste, autofs automounter and in-kernel iSCSI stack enhancements and bug fixes by Edward Tomasz Napierała, and updated vt(4) system console by Aleksandr Rybalko. A more detailed project update for each of the above projects can be found within this quarterly status report.

    We were a Gold Sponsor for NYCBSDCon�2014 in New York, February 8, which was attended by several board members. We were represented at SCALE in Los Angeles, February 22-23, and ICANN in Singapore, March 22-25.

    We were a sponsor for AsiaBSDCon in Tokyo, March 15-16. Board member Hiroki Sato was the conference organizer. Board members Kirk McKusick and George V. Neville-Neil taught tutorials and Kirk gave a keynote. Board member Dru Lavigne manned the foundation table and spoke at one of the sessions.

    We became a Gold+ sponsor for BSDCan�2014, May 16-17 and have started reaching out to vendors to attend the developer summit that runs in the two days before BSDCan.

    Board members George, Kirk, and Robert Watson pushed to finish the final draft of the next edition of their book The Design and Implementation of the FreeBSD Operating System.

    ITWire editor Sam Varghese published an interview with Kirk and Foundation technical manager Ed Maste about the status of secure boot on FreeBSD.

    The FreeBSD Logo is now officially a registered trademark to represent the FreeBSD operating system. We are working to expand the registration beyond just the FreeBSD operating system, but currently still have to use the TM symbol when using it on apparel and other non-operating-system items. We continued reviewing requests and granting permission to use FreeBSD trademarks.

    After finishing the 10.0-RELEASE, Foundation system administrator and release engineer Glen Barber began work on adding support for FreeBSD/arm image builds as part of the release build process. As a result of this work, FreeBSD/arm images are produced as part of the weekly development snapshot builds, and are available from any of the FreeBSD FTP mirrors. Supported kernel configurations currently include BEAGLEBONE, RPI-B, PANDABOARD, WANDBOARD-QUAD, and ZEDBOARD.

    George visited six large FreeBSD users in the Bay Area in February. These meetings are conducted to help facilitate collaboration between FreeBSD customers and the FreeBSD Project. It is an opportunity to exchange information on what the customers are doing and what is being worked on in the Project. It is also an opportunity to try to connect customers with the appropriate FreeBSD developers who may be working on areas of FreeBSD that interest these customers.

    News Home | Status Home