doc/en_US.ISO8859-1/htdocs/news/status/report-2014-04-2014-06.xml
Glen Barber 9a66b1c80a Fix rendering in vt(4) entry.
Sponsored by:	The FreeBSD Foundation
2014-07-13 17:59:00 +00:00

569 lines
19 KiB
XML

<?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 7 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 base for its NFS server, took
multiple optimizations to improve its performance and SMP
scalability. Algorithmic optimizations allowed to reduce
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 that allowed to increase peak NFS request rate
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 took series of locking optimization, that allowed
to increase its peak request rate from ~200K to ~600K IOPS
with potential of reaching reate of 1M request per second.
That rate is sufficient to completely saturage 2x10Gbit
Ethernet links with 4KB requests. For comparison, the port of
net/istgt (user-level iSCSI server) on the same hardware with
equal configuration shown only 100K IOPS.</p>
<p>There is also ongoing work on improving CTL functionality.
It was already made to support 3 of 4 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 above, and earlier improvements in CAM, GEOM, ZFS
and 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 start to 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>
</contact>
<links>
<url href="https://wiki.freebsd.org/Newcons">Project wiki
page</url>
</links>
<body>
<p>The <tt>vt(4)</tt> (a.k.a. <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 of 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, and it is controlled by a small module with just
one kernel environment variable <tt>kern.vty=syscons</tt> or
<tt>kern.vty=vt</tt>.</p>
<p>The GENERIC kernel configuration for the amd64 and i386
platforms include both <tt>syscons(4)</tt> and <tt>vt(4)</tt>
by default. Such configuration also planned to be in next
10-STABLE release, expected to be included in
&os;&nbsp;10.1-RELEASE.</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 campatibility mode to be able to use single-byte
charsets/key-codes in the <tt>vt(4)</tt>.</task>
</help>
</project>
<project cat='proj'>
<title>QEMU bsd-user 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 respository for collaboration</url>
</links>
<body>
<p>The ports-mgmt/poudriere-devel 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 setup the binmiscctl 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 setup
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>You can now run poudriere against that jail to build all the
ports:</p>
<p><tt>poudriere bulk -j 11armv632 -a</tt></p>
<p>Nullfs mount your 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. WIP as there appears 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 ports-mgmt/pkg. 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 devel/p5-Sys-SigAction
</task>
<task>
Massive documentation update needed. These modifications actually allow you to chroot into a MIPS or ARMv6 environment and use native tool chains and libraries to prototype your 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 support for
conflict-free Python package support across different Python
versions, based on the USES=uniquefiles feature recently
introduced to the Ports framework. This means that you can, in
theory, mark a Python package 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 will be to comply
to 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>Look at what adding pip (Python Package Index) support looks like.</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're
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>
<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>
</report>