os/doc
3
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity
doc/en_US.ISO8859-1/htdocs/news/status/report-2014-04-2014-06.xml
Ed Maste 9774d890cf Add portmgr report 
Was sent July 4, prior to the revamped monthly@ team
2014-07-17 12:09:41 +00:00

1549 lines
50 KiB
XML
Raw Blame History

<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE report PUBLIC "-//FreeBSD//DTD FreeBSD XML Database for
Status Report//EN"
"http://www.FreeBSD.org/XML/share/xml/statusreport.dtd" >
<!-- $FreeBSD$ -->
<report>
<date>
<month>April-June</month>
<year>2014</year>
</date>
<section>
<title>Introduction</title>
<p><strong>This is a draft of the April-June 2014 status report.
Please check back after it is finalized, and an announcement
email is sent to the FreeBSD-Announce mailing
list.</strong></p>
<p>This report covers &os;-related projects between April and
June 2014. This is the second of four reports planned for
2014.</p>
<?ignore
<p>The first quarter of 2014 was, again, a hectic and
productive time for &os;. The Ports team released their
landmark first quarterly <q>stable</q> branch. &os; 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 &os; hypervisor, continues to improve. An
integral test suite is taking shape, and the Jenkins Continuous
Integration system has been implemented. &os; patches to GCC
are being <q>forward-ported</q>, 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 <tt>vt</tt>, 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 &os; Foundation continues to assist in moving &os;
forward, sponsoring conferences and meetings and numerous
development projects. And these are only some of the things
that happened! Read on for even more.</p>
?>
<p>Thanks to all the reporters for the excellent work! This
report contains 20 entries and we hope you enjoy reading it.</p>
<p>The deadline for submissions covering between July and
September 2014 is October 7th, 2014.</p>
</section>
<category>
<name>team</name>
<description>&os; Team Reports</description>
</category>
<category>
<name>proj</name>
<description>Projects</description>
</category>
<category>
<name>kern</name>
<description>Kernel</description>
</category>
<category>
<name>arch</name>
<description>Architectures</description>
</category>
<category>
<name>bin</name>
<description>Userland Programs</description>
</category>
<category>
<name>ports</name>
<description>Ports</description>
</category>
<category>
<name>doc</name>
<description>Documentation</description>
</category>
<category>
<name>misc</name>
<description>Miscellaneous</description>
</category>
<project cat='proj'>
<title>CUSE4BSD</title>
<contact>
<person>
<name>
<given>Hans Petter</given>
<common>Selasky</common>
</name>
<email>hselasky@freebsd.org</email>
</person>
</contact>
<links>
<url
href="http://svnweb.freebsd.org/changeset/base/266581">Commit</url>
</links>
<body>
<p>The so-called "CUSE4BSD" has been imported into the base
system of &os;-11. CUSE is short for character device in
userspace. The CUSE library is a wrapper for the devfs(8)
kernel functionality which is exposed through /dev/cuse. In
order to function, the CUSE kernel code must either be enabled
in the kernel configuration file or loaded separately as
a module. Follow the commit message link to get more
information.
</p>
</body>
</project>
<project cat='proj'>
<title>RPC/NFS and CTL/iSCSI Performance Optimizations</title>
<contact>
<person>
<name>
<given>Alexander</given>
<common>Motin</common>
</name>
<email>mav@FreeBSD.org</email>
</person>
</contact>
<body>
<p>The &os; RPC stack, used as a base for its NFS server, received
multiple optimizations to improve performance and SMP
scalability. Algorithmic optimizations reduced
processing overhead, while improved locking allowed it to
scale up to at least 40 processor cores without significant
lock congestion. Combined with some other kernel
optimizations, the peak NFS request rate increased
by many times, reaching up to 600K requests per second on
modern hardware.</p>
<p>The CAM Target Layer (CTL), used as base for new kernel iSCSI
server, also received a series of locking optimizations which allowed
its peak request rate to increase from ~200K to ~600K IOPS
with the potential of reaching a rate of 1M requests per second.
That rate is sufficient to completely saturate 2x10Gbit
Ethernet links with 4KB requests. For comparison, the port of
net/istgt (user-level iSCSI server) on the same hardware with
an equivalent configuration showed only 100K IOPS.</p>
<p>There is also ongoing work on improving CTL functionality.
It was already made to support three of four VMware VAAI storage
acceleration primitives (net/istgt supports 2), while the goal
is to reach full VAAI support during next months.</p>
<p>With all these improvements, and earlier improvements in CAM, GEOM, ZFS,
and a number of other kernel areas coming soon, FreeBSD 10.1 may
become the fastest storage release ever. ;)</p>
<p>These projects are sponsored by iXsystems, Inc.</p>
</body>
</project>
<project cat="arch">
<title>FreeBSD/arm64</title>
<contact>
<person>
<name>
<given>Andrew</given>
<common>Turner</common>
</name>
<email>andrew@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="http://svnweb.freebsd.org/base/projects/arm64/" />
</links>
<body>
<p>Arm64 is the name of the in-progress port of &os; 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.</p>
<p>Booting &os; on the ARM Foundation Model has made a lot of
progress since the last status report. An initial pmap
implementation has been written. With this, &os; is able to
enter the Machine Independent boot code. The required
autoconf functions have been added allowing &os; to start
scheduling tasks. Finally the cpu_switch and copystr
functions were added. With these two, &os; will boot to the
mountroot prompt.</p>
<p>Work has started on supporting exceptions, including
interrupts. This will allow more developers to start
working on device drivers.</p>
</body>
<help>
<task>Finish exception and interrupt handling</task>
<task>Read the Device Tree or ACPI tables from UEFI</task>
<task>Test on real hardware</task>
</help>
</project>
<project cat='kern'>
<title>Updated <tt>vt(4)</tt> System Console</title>
<contact>
<person>
<name>
<given>Aleksandr</given>
<common>Rybalko</common>
</name>
<email>ray@FreeBSD.org</email>
</person>
<person>
<name>
<given>Ed</given>
<common>Maste</common>
</name>
<email>emaste@FreeBSD.org</email>
</person>
<person>
<name>
<given>Ed</given>
<common>Schouten</common>
</name>
<email>ed@FreeBSD.org</email>
</person>
<person>
<name>
<given>Warren</given>
<common>Block</common>
</name>
<email>wblock@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="https://wiki.freebsd.org/Newcons">Project wiki
page</url>
</links>
<body>
<p>The <tt>vt(4)</tt> (aka <tt>Newcons</tt>) project provides
a replacement for the legacy <tt>syscons</tt> system console.
It brings a number of improvements, including better
integration with graphics modes and broader character set
support.</p>
<p>Since the last <a
href="http://www.freebsd.org/news/status/report-2014-01-2014-03.html#Updated-vt%284%29-System-Console">report</a>,
<tt>vt(4)</tt> gained the ability to make early driver selection.
<tt>vt(4)</tt> selects the best successfully-probed driver before
most other kernel subsystems. Also, to make easy migration from
<tt>syscons(4)</tt> to <tt>vt(4)</tt>, multiple virtual
terminal subsystems in the kernel are now supported. It is
controlled by a small module with just one kernel environment
variable. Users can select the virtual terminal system to use by setting <tt>kern.vty=sc</tt> or
<tt>kern.vty=vt</tt>.</p>
<p>The GENERIC kernel configuration for the amd64 and i386
platforms now includes both <tt>syscons(4)</tt> and <tt>vt(4)</tt>
by default. This configuration is also planned to be in the
next 10-STABLE release and &os;&nbsp;10.1-RELEASE.</p>
<p>The project finally received a man page, so now <tt>vt(4)</tt> is not
only the project name, but also a link to its documentation. Great
thanks to &a.wblock; for that.</p>
<p>Major highlights:</p>
<ul>
<li>Unicode support.</li>
<li>Double-width character support for CJK characters.</li>
<li><tt>xterm(1)</tt>-like terminal emulation.</li>
<li>Support for Kernel Mode Setting (KMS) drivers
(<tt>i915kms</tt>, <tt>radeonkms</tt>).</li>
<li>Support for different fonts per terminal window.</li>
<li>Simplified drivers.</li>
</ul>
<p>Brief status of supported architectures and hardware:</p>
<ul>
<li>amd64 (VGA/<tt>i915kms</tt>/<tt>radeonkms</tt>) &mdash;
works.</li>
<li>ARM framebuffer &mdash; works.</li>
<li>i386 (VGA/<tt>i915kms</tt>/<tt>radeonkms</tt>) &mdash;
works.</li>
<li>IA64 &mdash; untested.</li>
<li>MIPS &mdash; untested.</li>
<li>PPC and PPC64 &mdash; work, but without X.Org yet.</li>
<li>SPARC &mdash; works on certain hardware (e.g., Ultra
5).</li>
<li><tt>vesa(4)</tt> &mdash; in progress.</li>
<li>i386/amd64 nVidia driver &mdash; not supported. VGA
should be used (VESA planned).</li>
<li>Xbox framebuffer driver &mdash; will be deleted as
unused.</li>
</ul>
</body>
<sponsor>The &os; Foundation</sponsor>
<help>
<task>Implement the remaining features supported by
<tt>vidcontrol(1)</tt>.</task>
<task>Write manual pages for <tt>vt(4)</tt> drivers and kernel
interface.</task>
<task>Support direct handling of keyboard by the <tt>kbd</tt>
device (without <tt>kbdmux(4)</tt>).</task>
<task>CJK fonts. (This is in progress).</task>
<task>Address performance issues on some architectures.</task>
<task>Switch to <tt>vt(4)</tt> by default.</task>
<task>Convert keyboard maps for use with <tt>vt(4)</tt>.</task>
<task>Implement compatibility mode to be able to use single-byte
charsets/key-codes in <tt>vt(4)</tt>.</task>
</help>
</project>
<project cat='proj'>
<title>QEMU <tt>bsd-user</tt>-Enabled Ports Building</title>
<contact>
<person>
<name>
<given>Stacey</given>
<common>Son</common>
</name>
<email>sson@freebsd.org</email>
</person>
<person>
<name>
<given>Juergen</given>
<common>Lock</common>
</name>
<email>nox@freebsd.org</email>
</person>
<person>
<name>
<given>Sean</given>
<common>Bruno</common>
</name>
<email>sbruno@freebsd.org</email>
</person>
</contact>
<links>
<url href="https://wiki.freebsd.org/QemuUserModeHowTo">Overview
of technology</url>
<url href="http://dirty.ysv.freebsd.org/">Status of ports
building</url>
<url href="https://github.com/seanbruno/qemu-bsd-user">Master
repository for collaboration</url>
</links>
<body>
<p>The <tt>ports-mgmt/poudriere-devel</tt> port is aware of how to build
ports via an emulator. Configuration of the miscellaneous
binary image activator is required prior to a poudriere-devel
run.</p>
<p>ARMV6, MIPS32 and MIPS64 packages can be produced via full
emulation. There are several packages that block a full run
of builds. They can be viewed on the "Status of ports building"
link.</p>
<p>On current or latest stable/10:</p>
<p>Clone the <url
href="https://github.com/seanbruno/qemu-bsd-user">github</url>
repository of qemu, and switch to the bsd-user branch. Then
run:</p>
<p><tt>./configure --static \<br/>
--target-list="arm-bsd-user i386-bsd-user \<br/>
mips-bsd-user mips64-bsd-user mips64el-bsd-user \<br/>
mipsel-bsd-user ppc-bsd-user ppc64-bsd-user sparc-bsd-user \<br/>
sparc64-bsd-user x86_64-bsd-user"</tt></p>
<p><tt>gmake; gmake install</tt></p>
<p>Then set up the <tt>binmiscctl</tt> tools to do some evil hackery to
redirect execution of armv6 binaries to qemu:</p>
<p><tt>binmiscctl add armv6 --interpreter \
"/usr/local/bin/qemu-arm" --magic \
"\x7f\x45\x4c\x46\x01\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02 \<br/>
\x00\x28\x00" --mask "\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff \<br/>
\xff\xff\xff\xff\xfe\xff\xff\xff" --size 20 --set-enabled</tt></p>
<p>Install poudriere-devel from ports. It knows how to set up
things.</p>
<p>Build poudriere jail to do all the magic:</p>
<p><tt>poudriere jail -c -j 11armv632 -m svn -a armv6 \<br/>
-v head</tt></p>
<p>Now run poudriere against that jail to build all the
ports:</p>
<p><tt>poudriere bulk -j 11armv632 -a</tt></p>
<p>Nullfs mount the ports tree into the jail:</p>
<p><tt>mkdir /usr/local/poudriere/jails/11armv632/usr/ports<br/>
mount -t nullfs /usr/ports /usr/local/poudriere/jails/11armv632/usr/ports</tt></p>
<p>To chroot into the jail:</p>
<p><tt>mount -t devfs devfs /usr/local/poudriere/jails/11armv632/dev<br/>
chroot /usr/local/poudriere/jails/11armv632/</tt></p>
</body>
<help>
<task>PPC on AMD64 emulation. This is a work in progress as there appear to be some
serious issues running the bsd-user binary on big-endian
hardware. Justin Hibbits working on this.</task>
<task>SPARC64 on AMD64 emulation is non-functional and instantly
segfaults. Looking for someone to poke at the bits
here.</task>
<task>External Tool Chain, XDEV support. Partial support for
using an AMD64 tool chain that can output other architecture
(use AMD64 toolchain to build MIPS64 packages). Currently
tracking a linking issue with <tt>ports-mgmt/pkg</tt>. Thanks to
Warner Losh, Baptiste Daroussin, Dimitry Andric for poking at
bits in here to make the XDEV target useful.</task>
<task>Signal handling, MIPS/ARMV6 target still displays a
failure that manifests itself when building
<tt>devel/p5-Sys-SigAction</tt>.</task>
<task>Massive documentation update needed. These modifications
actually allow chrooting into a MIPS or ARMv6 environment
and using native tool chains and libraries to prototype
software for a target platform.</task>
</help>
</project>
<project cat='ports'>
<title>&os; Python Ports</title>
<contact>
<person>
<name>
<given>&os;</given>
<common>Python Team</common>
</name>
<email>python@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="https://wiki.FreeBSD.org/Python">The &os; Python Team
Page</url>
<url href="irc://freebsd-python@irc.freenode.net">IRC
channel</url>
</links>
<body>
<p>We are pleased to announce the availability of conflict-free
Python package support across different Python versions based
on the USES=uniquefiles feature recently introduced to the
Ports framework. A Python package can be marked as buildable
and installable in parallel for different Python versions at
the same time on the same host. The package building tools,
however, do not support this feature yet and the Python team
will work closely with portmgr and pkg developers to enable
support on a global ports and package scale.</p>
<p>In May and June a huge clean-up operation took place to
remove the last bits and pieces targeting easy_install. In
the beginning of July we committed the final changes to remove
easy_install support completely from the ports framework.
This greatly simplifies the infrastructure and allows us to
modernize and maintain it with less effort.</p>
<p>We added Python 3.4, removed Python 3.1 after its end of
life, updated the setuptools ports to version 5.1 and PyPy's
development version to 2.3.1. The latest Python 2.7.8 and an
updated setuptools will hit the tree shortly.</p>
<p>Our upstreaming effort continues to produce good outcomes for
simplifying maintenance and reducing complexity.</p>
<p>Looking forward, one of the top priorities is to comply with
the USES framework in the foreseeable future and to roll out a
consistent maintainer policy for integrating new
Python-related ports into the tree.</p>
</body>
<help>
<task>Migrate bsd.python.mk to the Uses framework.</task>
<task>Develop a high-level and lightweight Python Ports
Policy.</task>
<task>Add support for granular dependencies (for example
&gt;=1.0,&lt;2.0).</task>
<task>See what adding pip (Python Package Index) support will
require.</task>
<task>Add default QA targets and functions for Python ports
(TEST_DEPENDS, regression-test, etc.)</task>
<task>More tasks can be found on the team's wiki page (see
links).</task>
<task>To get involved, come and say "hi" on IRC and let us know
what you are interested in!</task>
</help>
</project>
<project cat='kern'>
<title>UEFI Boot</title>
<contact>
<person>
<name>
<given>Ed</given>
<common>Maste</common>
</name>
<email>emaste@FreeBSD.org</email>
</person>
<person>
<name>
<given>Nathan</given>
<common>Whitehorn</common>
</name>
<email>nwhitehorn@freebsd.org</email>
</person>
</contact>
<links>
<url href="https://wiki.freebsd.org/UEFI">&os; UEFI wiki
page</url>
</links>
<body>
<p>The Unified Extensible Firmware Interface (UEFI) provides
boot- and run-time services for x86 and other computers. For
the x86 architecture it replaces the legacy BIOS. This
project will adapt the &os; loader and kernel boot process for
compatibility with UEFI firmware, found on contemporary
servers, desktops, and laptops.</p>
<p>Ed and Nathan completed a number of integration tasks over
the past three months. Nathan added a first-stage loader,
boot1.efi, to support chain-loading the rest of the system
from a UFS filesystem. This allows the UEFI boot process to
proceed in a similar fashion as with BIOS boot. Nathan also
added UEFI support to the &os; installer and release image
creation script.</p>
<p>The EFI framebuffer requires the vt(4) system console &mdash;
a framebuffer driver is not implemented for the legacy
syscons(4) console. Ed added automatic vt(4) selection to the
UEFI boot path.</p>
<p><url
href="http://www.freebsd.org/snapshots/">&os;&nbsp;snapshots</url>
are now built as dual-mode images, and should boot via BIOS
and UEFI. Our plan is to merge the UEFI and vt(4) work to
stable/10 to appear in &os; 10.1-RELEASE.</p>
</body>
<sponsor>The &os; Foundation</sponsor>
<help>
<task>Document manual installation, including dual-boot
configurations.</task>
<task>Implement boot1.efi for ZFS file systems.</task>
<task>Add support for UEFI variables stored in non-volatile
memory (NVRAM).</task>
<task>Debug boot failures with certain UEFI firmware
implementations.</task>
<task>Support secure boot.</task>
</help>
</project>
<project cat='team'>
<title>&os; Core Team</title>
<contact>
<person>
<name>&os; Core Team</name>
<email>core@FreeBSD.org</email>
</person>
</contact>
<body>
<p>The &os; 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
&os; project landscape.</p>
<p>Topics for core this quarter have included some far-reaching
policy reviews and some significant changes to the project
development methodology.</p>
<p>In May, a new release policy was published and
presented at the BSDCan developer conference by John Baldwin.
The idea is that each major release branch (for example, 10.X) is
guaranteed to be supported for at least five years, but
individual point releases on each branch, like 10.0-RELEASE,
will be issued at regular intervals and only the latest point
release will be supported.</p>
<p>Another significant change did not receive approval. When
the change to the Bylaws reforming the core team election
process was put to the vote of all &os; developers, it failed
to reach a quorum.</p>
<p>June saw the culmination of a long running project to replace
the project's bug tracking system. As of June 3, the &os;
project has switched to Bugzilla as its bug tracking system.
All of the history of GNATS PRs has been preserved, so there
is no need to re-open old tickets. Work is still going on to
replicate some of the integration tweaks that had been applied
to GNATS, but all necessary functionality has been implemented
and the project is already seeing the benefits of the new
capabilities brought by Bugzilla.</p>
<p>An election to select core members for the next two year term
of office took place during this period. We would like to
thank retiring members of core for their years of service.
The new core team provides continuity with previous core
teams: about half are incumbents from the previous team, and
several former core team members have returned after a hiatus.
Core now includes two members of the &os; Foundation board and
one other Foundation staff member, aiding greater coordination
at the top level of the project. At the same time the
core-secretary role was passed on to a new volunteer.</p>
<p>Other activities included providing consultation on licensing
terms for software within the &os; source tree, and oversight
of changes to the membership of postmaster and clusteradm.</p>
<p>Three new src commit bits were issued during this quarter,
and one was taken into safekeeping.</p>
</body>
</project>
<project cat='misc'>
<title>&os; Host Support for OpenStack and OpenContrail</title>
<contact>
<person>
<name>
<given>Grzegorz</given>
<common>Bernacki</common>
</name>
<email>gjb@semihalf.com</email>
</person>
<person>
<name>
<given>Michal</given>
<common>Dubiel</common>
</name>
<email>md@semihalf.com</email>
</person>
<person>
<name>
<given>Dominik</given>
<common>Ermel</common>
</name>
<email>der@semihalf.com</email>
</person>
<person>
<name>
<given>Rafal</given>
<common>Jaworowski</common>
</name>
<email>raj@semihalf.com</email>
</person>
</contact>
<links>
<url href="http://www.openstack.org" />
<url href="http://www.opencontrail.org" />
<url href="https://github.com/Semihalf/openstack-devstack" />
<url href="https://github.com/Semihalf/openstack-nova" />
<url href="https://github.com/Semihalf/contrail-vrouter" />
<url href="https://blueprints.launchpad.net/nova/+spec/freebsd-compute-node" />
</links>
<body>
<p>OpenStack is a cloud operating system that controls large
pools of compute, storage, and networking resources in
a datacenter.</p>
<p>OpenContrail is a network virtualization (SDN) solution
comprising network controller, virtual router, and analytics
engine, which can be integrated with cloud orchestration
systems like OpenStack or CloudStack.</p>
<p>This work's goal is to enable &os; as a fully supported
compute host for OpenStack using OpenContrail virtualized
networking. The main areas of development are:</p>
<ul>
<li>Libvirt hypervisor driver for bhyve.</li>
<li>Support for bhyve (via libvirt compute driver) and &os;
platform in overall in nova-compute.</li>
<li>OpenContrail vRouter (forwarding plane kernel module) port
to &os;.</li>
<li>OpenContrail Agent (network controller node) port to
&os;.</li>
<li>Integration, performance optimizations.</li>
</ul>
<p>Since the last report the following items have been
completed, which allow for a working demo of OpenStack compute
node on a &os; host using OpenContrail solution for network
virtualization:</p>
<ul>
<li>Port of the OpenContrail vRouter kernel module for &os;
(MPLS over GRE mode only)</li>
<li>Port of the OpenContrail Agent for &os;</li>
<li>&os; version of a Devstack installation/configuration
script with support for the OpenContrail solution (Compute
node components only)</li>
</ul>
<p>A demo was presented at the DevSummit during BSDCan2014
in Ottawa. Also, a meetup regarding the subject was organized
in Krakow, Poland.</p>
<p>Work on this project is sponsored by Juniper Networks.</p>
</body>
</project>
<project cat='misc'>
<title>The &os; Foundation</title>
<contact>
<person>
<name>
<given>Deb</given>
<common>Goodkin</common>
</name>
<email>deb@FreeBSDFoundation.org</email>
</person>
</contact>
<links>
<url href="http://www.FreeBSDFoundation.org/"/>
<url href="http://freebsdjournal.com/">&os; Journal</url>
</links>
<body>
<p>The &os; Foundation is a 501(c)(3) non-profit organization
dedicated to supporting and promoting the &os;&nbsp;Project
and community worldwide. Most of the funding is used to
support &os; development projects, conferences and developer
summits, purchase equipment to grow and improve the &os;
infrastructure, and provide legal support for the Project.</p>
<p>We published our third issue of the &os; Journal. We have
over 2700 subscriptions so far. We continued working on the
digital edition, which will allow subscribers to read the
magazine in different web browsers, including those than run
on &os;. This will be available for the July/August issue of
the Journal.</p>
<p>We hired Anne Dickison, on a freelance basis, as our new
marketing director, to help us promote the Foundation and
Project.</p>
<p>The annual board meeting was held in Ottawa, Canada, in May.
Directors and officers were elected, and did some long term
planning. We worked on our vision, core values, project road
mapping, and our near term goals. We also met with the core
team to discuss roles and responsibilities, project
roadmapping, and what we can do to help the Project more.</p>
<p>We were a Gold+ sponsor for BSDCan, May 16-17 and provided
7 travel grants for developers to attend the conference. We
also were the sponsor for both the developer and vendor
summits.</p>
<p>Justin Gibbs gave a &os; presentation at a &os; user's
internal technology summit. Company visits like this help
users understand the Project structure better and gives us
a chance to communicate what &os; people are working on as
well as learn what different companies are doing with &os;, as
well as what they'd like to see supported. We can then help
facilitate collaboration between the companies and &os;
developers.</p>
<p>We were represented at Great Wide Open, April 2-3
(greatwideopen.org), Texas LinuxFest, June 13-14
(texaslinuxfest.org), and SouthEast LinuxFest, June 20-22
(southeastlinuxfest.org).</p>
<p>Hardware was purchased to support an upgrade at Sentex. A new
high capacity 1Gbps switch was deployed to allow for more
systems to be added to the test lab. The main file server and
development box was upgraded to allow more users in the lab
simultaneously.</p>
<p>We purchased hardware, including package builders, and
a larger server to allow NYI to be a full replica of all
Project systems, comparable to what is in place at Yahoo Inc.
and ISC.</p>
<p>We worked with our lawyer to create an NDA between the
Foundation and individuals for third party NDAs. This allows
developers who need access to proprietary documents, to go
through the Foundation, via an NDA for access.</p>
<p>&os; Foundation Systems Administrator and Release Engineer,
Glen Barber, continued work on producing regularly-updated
&os;/arm snapshots for embedded devices, such as the
Raspberry Pi, ZedBoard, and BeagleBone.</p>
<p>In addition to producing weekly development snapshots from
the head/ and stable/ branches, with feedback and help from Ed
Maste, Glen finished work to produce release images that will,
by default, provide debugging files for userland and kernel
available on the &os;&nbsp;Project FTP mirrors. Note that the
debugging files will not be included on the bootonly.iso,
disc1.iso, or dvd1.iso images due to the size of the resulting
images.</p>
<p>Foundation staff member Konstantin Belousov completed an
investigation into poor performance of PostgreSQL on &os;.
This uncovered scalability problems in the &os; kernel, and
changes to address these issues are in progress.</p>
<p>Some previously completed Foundation-sponsored projects
received enhancements or additional work. The ARM
superpages project was completed last year, but is now enabled
by default in &os;-CURRENT. Many stability fixes and
enhancements have been committed to the in-kernel iSCSI stack.
The iSCSI project was released in &os;&nbsp;10.0. Many
stability fixes and enhancements have been committed and will
be included in &os;&nbsp;10.1.</p>
<p>Work continues on the Foundation-sponsored autofs automount
daemon, UEFI boot support, the updated vt(4) system video
console, virtual machine images, and the Intel graphics driver
update. Foundation-sponsored work resulted in
226 commits to &os; over the April to June period.</p>
</body>
</project>
<project cat='kern'>
<title>SDIO Driver</title>
<contact>
<person>
<name>
<given>Ilya</given>
<common>Bakulin</common>
</name>
<email>ilya@bakulin.de</email>
</person>
</contact>
<links>
<url href="https://wiki.freebsd.org/SDIO">SDIO project page on
&os;&nbsp;Wiki</url>
<url href="https://github.com/kibab/freebsd/tree/mmccam">Source
code</url>
</links>
<body>
<p>SDIO is an interface designed as an extension of the existing
SD card standard, which allows connecting different peripherals to
the host with the standard SD controller. Peripherals
currently sold at the general market include WLAN/BT modules,
cameras, fingerprint readers, and barcode scanners.
Additionally, SDIO is used to connect some peripherals in
products like Chromebooks and Wandboard. A prototype of the
driver for the Marvell SDIO WLAN/BT (Avastar 88W8787) module
is also being developed, using the existing Linux driver as
the reference.</p>
<p>SDIO card detection and initialization already work, most
needed bus methods are implemented and tested.</p>
<p>The WiFi driver is able to load firmware onto the card and
initialize it. A rewrite of the MMC stack as a transport
layer for the CAM framework is in progress. This will allow
utilization of the well-tested CAM locking model and debug features.</p>
</body>
<help>
<task>SDIO stack: finish CAM migration. The initialization of
MMC/SD card is implemented in the XPT layer, but cannot be
tested with real hardware because of the lack of any device
drivers that implement peripheral drivers and SIMs for CAM
MMC. The plan is to use a modified version of BeagleBone Black
SDHCI controller driver for SIM and a modified version of
mmcsd(4) as a peripheral driver.</task>
<task>Marvell SDIO WiFi: connect to the &os; network stack,
write the code to implement required functions (such as
sending/receiving data, network scanning and so on).</task>
</help>
</project>
<project cat='team'>
<title>&os; Release Engineering Team</title>
<contact>
<person>
<name>
<given>&os;</given>
<common>Release Engineering Team</common>
</name>
<email>re@FreeBSD.org</email>
</person>
</contact>
<links>
<url
href="http://www.freebsd.org/releases/9.3R/schedule.html">&os;&nbsp;9.3-RELEASE schedule</url>
<url
href="http://ftp.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/">&os; development snapshots</url>
</links>
<body>
<p>The &os; Release Engineering Team is responsible for setting
and publishing release schedules for official project releases
of &os;, and announcing code freezes and maintaining the
respective branches, among other things.</p>
<p>In early May, the &os;&nbsp;9.3-RELEASE cycle entered the
code slush phase. The &os;&nbsp;9.3-RELEASE cycle is nearing
the final phases, and 9.3-RC3 builds will be starting soon.
9.3-RC3 is planned to be the final release candidate for this
release cycle, and at the time of this writing, 9.3-RELEASE
should be available on schedule.</p>
<p>Work is ongoing to integrate support for embedded
architectures into the release build process. At this
time, support exists for a number of ARM kernels, in
particular the Raspberry Pi, BeagleBone, and WandBoard.</p>
<p>Additionally, work is in progress to produce virtual machine
images as part of the release cycle, supporting various cloud
services such as Microsoft Azure, Amazon EC2, and Google
Compute Engine.</p>
</body>
<sponsor>
The FreeBSD Foundation
</sponsor>
<help></help>
</project>
<project cat='kern'>
<title>Running &os; as an Application on Top of the Fiasco.OC
Microkernel</title>
<contact>
<person>
<name>
<given>Ilya</given>
<common>Bakulin</common>
</name>
<email>ilya@bakulin.de</email>
</person>
</contact>
<links>
<url href="http://en.wikipedia.org/wiki/L4_microkernel_family">L4
microkernel family</url>
<url href="https://wiki.freebsd.org/201407DevSummit/BSDUserspace">A
brief description of the project on the &os; wiki (short talk
during &os; DevSummit in Cambridge)</url>
</links>
<body>
<p>Fiasco.OC belongs to the L4 microkernel family. A microkernel
provides a bare minimum of services to the applications
running on top of it, unlike traditional kernels that
incorporate complex code like IP stacks and device drivers.
This allows a dramatic decrease in the amount of code
running in the privileged mode of the CPU, achieving higher
security while still providing an acceptable level of
performance.</p>
<p>Running an operating system kernel on top of the microkernel
allows leveraging any software that was developed for that
operating system. The OS kernel runs in user-mode side-by-side
with other microkernel applications such as real-time
components. Multiple OSes, each with their userland
applications, can even be run in parallel, thus allowing
construction of products where processing of corporate data is
strictly separated from the processing of private data.</p>
<p>The project aims to create a port of &os; to the Fiasco.OC
microkernel, a high performance L4 microkernel
developed by TU Dresden. Existing ports of OpenBSD and
Linux are used as a reference. This will allow the use of
unique &os; features like ZFS in L4-based projects.</p>
</body>
<help>
<task>Finish opensourcing the port of L4OpenBSD/amd64 made by
genua mbh. This is a work in progress.</task>
<task>Publish the sources of the L4&os; port that is largely based
on the L4OpenBSD code.</task>
<task>Improve the port, the first task being adopting the
pmap(9) module to work with L4 microkernel memory allocation
services.</task>
</help>
</project>
<project cat="proj">
<title>pkg(8)</title>
<contact>
<person>
<name>
<given>Baptiste</given>
<common>Daroussin</common>
</name>
<email>bapt@FreeBSD.org</email>
</person>
<person>
<name>
<given>Bryan</given>
<common>Drewery</common>
</name>
<email>bryan@FreeBSD.org</email>
</person>
<person>
<name>
<given>Matthew</given>
<common>Seaman</common>
</name>
<email>matthew@FreeBSD.org</email>
</person>
<person>
<name>
<given>Vsevolod</given>
<common>Stakhov</common>
</name>
<email>vsevolod@FreeBSD.org</email>
</person>
<person>
<name>The pkg mailing list</name>
<email>freebsd-pkg@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="https://github.com/freebsd/pkg">The main pkg(8) git
repository.</url>
<url href="https://github.com/freebsd/pkg/issues">The preferred
place to raise bug reports concerning pkg(8).</url>
</links>
<body>
<p>pkg(8) is the new package management tool for &os;. It
is now the only supported package management tool for &os;
releases from 10.0-RELEASE, including the upcoming
9.3-RELEASE. pkg(8) is available on all currently supported
releases. Support for the legacy pkg_tools is due to be
discontinued at the beginning of September 2014.</p>
<p>The release of pkg(8) 1.3 is imminent. This includes major
improvements in the dependency solver. Now we can:</p>
<ul>
<li>Switch versions of, for example, Perl or PHP and resolve all the
conflicts with packages that depend on them automatically.
No more need to manually switch package origins.</li>
<li>Deal more gracefully with complex upgrade or install
scenarios.</li>
<li>Sandbox operations dealing with freshly downloaded data
until it can be verified as trustworthy by checking the
package signature.</li>
<li>Deal with provides-and-requires style of dependencies, so
for example we can say "this package needs to use a web
server" and allow that dependency to be fulfilled by apache
or nginx or any other alternative that provides web-server
functionality.</li>
</ul>
<p>Beyond the next release, we have work in progress on allowing
ranges of versions in dependency rules and handling
a selection of "foreign" package repositories, such as CPAN or
CTAN or PyPi.</p>
<p>There are plans to use pkg(8) to package up the base system.
Along with other benefits, this will allow writing a universal
installer: download one installer image and from
there install any available version of &os;, including
snapshots.</p>
<p>We are also intending to use pkg(8) within the ports tree at
package-build time to handle fulfilling build dependencies.
This opens the possibility of installing build-dependencies by
downloading binary packages, which means you can install
a package with customized options with the minimum amount of
time spent compiling anything else.</p>
</body>
<help>
<task>We are sorely lacking a comprehensive testing setup.
Integrating automated regression testing into the development
cycle is becoming an imperative.</task>
<task>We need testers who can run development versions of pkg in
as many distinct types of use-case as possible, and feedback
their experiences via the freebsd-pkg@freebsd.org mailing list
or our <url
href="https://github.com/freebsd/pkg/issues">issues list on
github</url>.</task>
</help>
</project>
<project cat="ports">
<title>The Graphics stack on &os;</title>
<contact>
<person>
<name>
<common>&os; Graphics team</common>
</name>
<email>x11@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="https://wiki.freebsd.org/Graphics">Graphics stack
roadmap and supported hardware matrix</url>
<url
href="http://lists.freebsd.org/pipermail/freebsd-announce/2014-July/001570.html">WITH_NEW_XORG
repository announce</url>
<url
href="http://trillian.chruetertee.ch/ports/browser/trunk">Ports-related
development repository</url>
</links>
<body>
<p>We were generally short on time this quarter. We made less
progress than expected on all fronts.</p>
<p>The alternate pkg(8) repository, built with WITH_NEW_XORG, is
now available. This alleviates the need for users to rebuild
their ports with WITH_NEW_XORG. See the announcement, linked
above for further information.</p>
<p>Thanks to a contribution from Jan Kokemüller, Radeon 32bit
ioctls are now working on 64bit hosts. This was tested
successfully with Wine and StarCraft II on &os; 9.x and 11.
This required modifications to <tt>emulators/i386-wine-devel</tt> so
that it works with WITH_NEW_XORG, and the creation of a new
port, <tt>libtxc_dxtn</tt>, to support texture compression required by
StarCraft II. We haven't yet had the time to polish
everything, so this still requires manual steps.</p>
<p>The DRM generic code update is ready, but it breaks the
current i915 driver. Therefore, the i915 driver must be
updated before anything is committed.</p>
<p>Compared to the previous status report, OpenCL test programs are
running fine now, thanks to upgrades and fixes to libc++ and
Clang. Relevant ports are still not ready to hit the ports
tree, unfortunately.</p>
</body>
<help>
<task>See the "Graphics" wiki page for up-to-date
information.</task>
</help>
</project>
<project cat='proj'>
<title>Chelsio iSCSI offload support</title>
<contact>
<person>
<name>
<given>Sreenivasa</given>
<common>Honnur</common>
</name>
<email>shonnur@chelsio.com</email>
</person>
</contact>
<links></links>
<body>
<p>Building on the new in-kernel iSCSI target and initiator
stack released in FreeBSD 10.0, Chelsio Communications has
begun developing an offload interface to take advantage of the
hardware offload capabilities of Chelsio T4 and T5 10 and 40
gigabit Ethernet adapters.</p>
<p>The code currently implements a working prototype of offload
for the initiator side, and target side offload should begin
shortly. The code will be released under the BSD license and
is expected to be completed later in the year and be committed
to FreeBSD-HEAD, and will likely ship in a FreeBSD release in
early 2015.</p>
</body>
<help>
<task>Complete testing and debugging of the initiator
offload.</task>
<task>Start development of target offload.</task>
<task>Create hardware-independent offload APIs, based on
experiences with target and initiator proof-of-concept
implementations.</task>
</help>
</project>
<project cat='kern'>
<title>TMPFS Stability</title>
<contact>
<person>
<name>
<given>Konstantin</given>
<common>Belousov</common>
</name>
<email>kib@FreeBSD.org</email>
</person>
<person>
<name>
<given>Peter</given>
<common>Holm</common>
</name>
<email>pho@FreeBSD.org</email>
</person>
</contact>
<body>
<p>Extensive testing of tmpfs(5) using the stress2 kernel test
suite was done. The issues found were debugged and fixed.</p>
<p>Most of the problems are related to the bugs in the
interaction of vnode and node lifetime, culminating in e.g.
unmount races and dotdot lookup bugs.</p>
<p>This project is sponsored by the FreeBSD Foundation.</p>
</body>
<sponsor>The &os; Foundation</sponsor>
</project>
<project cat='kern'>
<title>PostgreSQL performance improvements</title>
<contact>
<person>
<name>
<given>Konstantin</given>
<common>Belousov</common>
</name>
<email>kib@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="https://www.kib.kiev.ua/kib/pgsql_perf_v2.0.pdf" />
</links>
<body>
<p>The analysis of the performance of the latest 9.3 version of
the PostgreSQL on &os;-CURRENT was performed. The issues
which prevented the good scalability on a 40-core machine were
determined, and changes prototyped which solve the
bottlenecks.</p>
<p>The URL above provides a paper which contains a detailed
explanation of the issues and solutions, together with the
graph demonstrating the effects on scalability.</p>
</body>
<sponsor>The &os; Foundation</sponsor>
</project>
<project cat='proj'>
<title>ZFSguru</title>
<contact>
<person>
<name>
<given>Jason</given>
<common>Edwards</common>
</name>
<email>sub.mesa@gmail.com</email>
</person>
</contact>
<links>
<url href="http://zfsguru.com" />
</links>
<body>
<p>ZFSguru is a multifunctional server appliance with a strong
emphasis on storage. ZFSguru began as simple web-interface
frontend to ZFS, but has since grown into a &os; derivative
with its own infrastructure. The scope of the project has
also grown with the inclusion of add-on packages that add
functionality beyond the traditional NAS functionality found
in similar product like FreeNAS and NAS4Free. ZFSguru aims to
be a true multifunctional server appliance that is extremely
easy to setup and can unite both novice and more experienced
users in a single user interface. The modular nature of the
project combats the danger of bloat, whilst still allowing
extended functionality to be easily deployed.</p>
<p>Where development in the first quarter of this year brought
drag-and-drop permissions for Samba and NFS, development in
the second quarter focused on strengthening the infrastructure
of the project. A new library and toolkit solution dubbed
'Mesa' is in the works, providing a cleaner foundation to the
project. A new master server providing secure remote services
is being setup, to be located in a high-speed datacenter. But
most importantly, a new system build infrastructure has shown
great progress and will soon be able to provide automated
system builds to our users. This not only improves the
frequency of system releases but also frees much developer
time to be spent on different areas of the project.</p>
<p>Furthermore, a new website and forum is being worked at,
replacing the old-fashioned website that offers only limited
functionality. The new website will be linked to the server
database, providing real-time updates about the project.</p>
<p>In addition, a new platform for collaborated development is
in the works. A service addon has been created for the GitLab
project, which is a drop-in replacement of the popular GitHub
website. The choice was made to host our own solution and not
rely on GitHub itself. In retrospect this appears to be a good
decision. The recent development where GitHub removed projects
after DCMA-takedowns being sent is incompatible with the
philosophy of free-flow-of-information, which the ZFSguru
project is a strong proponent of. By hosting our own solution,
we have avoided any dependency on third party projects.</p>
<p>It is expected that after the infrastructure of the project
has been revamped, work on the web-interface itself can
continue. New functionality such as GuruDB and Service
Bulletins provide a tighter connection between the server
infrastructure and the web-interface. The Migration Manager
is one of the last remaining features still missing in the
web-interface. This functionality provides an easy way to
upgrade the current system by performing a new clean
installation, but migrate all relevant configuration to the
new installation. It also allows to 'backup' all system
configuration in a single file to be stored on a different
machine should things go awry.</p>
<p>A longer version of this status report giving a wider
perspective on the project, can be found <url
xlink:href="http://zfsguru.com/news/stateoftheproject/2014">here</url>.</p>
</body>
</project>
<project cat='proj'>
<title>FreeBSD and Summer of Code 2014</title>
<contact>
<person>
<name>
<given>Gavin</given>
<common>Atkinson</common>
</name>
<email>gavin@FreeBSD.org</email>
</person>
<person>
<name>
<given>Glen</given>
<common>Barber</common>
</name>
<email>gjb@FreeBSD.org</email>
</person>
<person>
<name>
<given>Wojciech</given>
<common>Koszek</common>
</name>
<email>wkoszek@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="http://gsoc.FreeBSD.org" />
<url href="https://wiki.freebsd.org/SummerOfCode2014" />
</links>
<body>
<p>FreeBSD received 39 project proposals this year, many of
which were of a very high standard. After a difficult
selection process narrowing these down into the slots we had
been allocated, a total of 16 projects were selected to
participate in Google Summer of Code 2014 with FreeBSD.</p>
<p>Projects selected cover a wide range of areas within FreeBSD,
covering both the base system and ports infrastructure,
userland and kernel. We have students working on firewall
optimisation, ports packaging tools, embedded systems,
debugging infrastructure, improved Unicode support, enhancements
to the loader and to the installer, and several other areas of
work. We are just over half way through the allocated time this
year, and are very much looking forward to integrating code
produced by these projects into FreeBSD.</p>
<p>This is the tenth time FreeBSD has taken part in Google's
Summer of Code, and we are grateful to Google to have accepted
us as a participating organisation.</p>
</body>
</project>
<project cat='ports'>
<title>&os; Port Management Team</title>
<title>FreeBSDPorts Collection</title>
<contact>
<person>
<name>
<given>Frederic</given>
<common>Culot</common>
</name>
<email>portmgr-secretary@FreeBSD.org</email>
</person>
<person>
<name>
<given>Port</given>
<common>Management Team</common>
</name>
<email>portmgr@FreeBSD.org</email>
</person>
</contact>
<links>
<url href="http://www.FreeBSD.org/ports/" />
<url href="http://www.freebsd.org/doc/en_US.ISO8859-1/articles/contributing-ports/" />
<url href="http://portsmon.freebsd.org/index.html" />
<url href="http://www.freebsd.org/portmgr/index.html" />
<url href="http://blogs.freebsdish.org/portmgr/" />
<url href="http://www.twitter.com/freebsd_portmgr/" />
<url href="http://www.facebook.com/portmgr" />
<url href="http://plus.google.com/communities/108335846196454338383" />
</links>
<body>
<p>The ports tree slowly approaches the 25,000 ports threshold, while the
PR count is slightly below 1800.</p>
<p>In Q2 we added three new committers, took in one commit bit for
safe keeping, and reinstated one commit bit.</p>
<p>In May, tabthorpe@ was replaced by culot@ as portmgr secretary, and
swills@ became a member of the portmgr team.</p>
<p>Commencing July 1, the third intake portmgr-lurkers@ started
active duty on portmgr@ for a four month duration. The next two
candidates are wg@ and nivit@.</p>
<p>This quarter also saw the release of the second quarterly branch,
namely 2014Q2. This branch was not only built for 10 (as 2014Q1) but
for 9 as well (both i386 and amd64).</p>
</body>
<help>
<task>As previously noted, many PRs continue to languish, we would
like to see committers dedicate themselves to closing as many
as possible.</task>
</help>
</project>
</report>
Reference in a new issue View git blame Copy permalink