os/doc
3
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

- Further improvements to the 2014Q1 status report

Browse source 
Submitted by:	bjk (most of them)
This commit is contained in:
Gabor Pali 2014-04-17 17:22:59 +00:00
parent 07f6c83bcd
commit 0cde51f928
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/head/; revision=44594
1 changed files with 114 additions and 115 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

229
en_US.ISO8859-1/htdocs/news/status/report-2014-01-2014-03.xml
View file

@ -212,12 +212,12 @@
definitions and explanations of the terms and features of
ZFS.</p>
<p>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, a use cases section that highlights
some of the cases where ZFS provides advantages over
<p>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.</p>
<p>Please send suggestions to the <tt>freebsd-doc</tt> mailing
@ -296,10 +296,10 @@
<body>
<p>The &os; Documentation Engineering Team is responsible for
defining and following up documentation goals for the
committers in the Documentation project. The team is pleased
to announce a new member &mdash; &a.wblock;. In early March,
the &os; Documentation Engineering Team members assumed
defining and following up on the documentation goals for the
committers in the Documentation project. The team is pleased to
announce a new member &mdash; &a.wblock;. In early March, the
&os; Documentation Engineering Team members assumed
responsibility for the &os; Webmaster Team.</p>
</body>
</project>
@ -342,10 +342,10 @@
currently at its most recent upstream version.</p>
<p>For non-Windows-based Ada development, &os; and DragonFly are
now undisputed as the go-to platforms. The other candidates
are Debian and Fedora, but there are few Ada software on those
platforms that are not also in the &os; ports tree, but the
versions are much older. The Ports Collection also features
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 &os; ports tree, and the &os;
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.</p>
@ -407,7 +407,7 @@
</ul>
<p>We also follow development of core components (available in
your repository). See link for documentation on how to
your repository). See the links for documentation on how to
upgrade those libraries.</p>
<ul>
@ -574,8 +574,8 @@
<task>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,
date and duration of the whole run, or list of installed
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.</task>
<task>Add JUnit XML output to Kyua for better integration with
@ -689,15 +689,15 @@
</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>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>Progress has been good on getting &os; to build and run on
the ARM Foundation model. &os; is able to be built for this
architecture, however it requires a number of external tools
architecture, however, it requires a number of external tools
including <tt>objdump(1)</tt> and <tt>ld(1)</tt>. These tools
are provided by an external copy of binutils until
replacements can be written.</p>
@ -871,7 +871,7 @@
<task>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 NX stack.</task>
implemented ASLR requires a NX stack.</task>
<task>Shawn will be receiving a <tt>sparc64</tt> box on April 6,
2014. He will test ASLR on <tt>sparc64</tt>, identifying and
@ -881,9 +881,9 @@
Linuxulator. He will be looking into that and fixing
those.</task>
<task>Shawn will be cleaning up code and adding more
applications in base to support PIE. He will also add PIE
support to the ports framework for general consumption.</task>
<task>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.</task>
<task>Shawn will be giving a presentation regarding ASLR at
BSDCan&nbsp;2014.</task>
@ -1123,12 +1123,12 @@
</links>
<body>
<p>Chromebook is an ARMv7 Cortex-A15 personal computer powered
by Samsung Exynos 5 Dual System-on-Chip. As of the current
status of this project, such laptops can be booted with &os;
from USB flash &mdash; it works stably (including SMP) and it
can build third-party applications. The display and keyboard
work.</p>
<p>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 &os; from USB flash &mdash; it works stably (including SMP)
and it can build third-party applications. The display and
keyboard work.</p>
<p>Thanks to &a.grehan; for providing hardware.</p>
</body>
@ -1382,7 +1382,7 @@
<p>The project is now in <tt>head</tt>, <tt>stable/10</tt> and
<tt>stable/9</tt> branches. Hence, <tt>vt(4)</tt> can be
tested by using <tt>VT</tt> kernel configuration
tested by using the <tt>VT</tt> kernel configuration
(<tt>i386</tt> and <tt>amd64</tt>) or by replacing two lines
in the <tt>GENERIC</tt> kernel configuration file:</p>
@ -1439,7 +1439,7 @@ device vt_efifb</pre>
<task>Create sub-directories for <tt>vt(4)</tt> under
<tt>/usr/share/</tt> to store key maps and fonts.</task>
<task>Implement remaining features supported by
<task>Implement the remaining features supported by
<tt>vidcontrol(1)</tt>.</task>
<task>Write the <tt>vt(4)</tt> manual page. (This is in
@ -1529,7 +1529,7 @@ device vt_efifb</pre>
<p>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 network controller, virtual router and
solution comprising a network controller, virtual router, and
analytics engine, which can be integrated with cloud
orchestration systems like OpenStack or CloudStack.</p>
@ -1718,10 +1718,10 @@ device vt_efifb</pre>
&os;. The second was <tt>auditdistd(8)</tt> improvements for
the &os; cluster.</p>
<p>Work continued on these Foundation-sponsored projects:
Intel graphics driver update by &a.kib;, UEFI boot support for
<p>Work continued on these Foundation-sponsored projects: Intel
graphics driver update by &a.kib;, UEFI boot support for
<tt>amd64</tt> by &a.emaste;, autofs automounter and in-kernel
iSCSI stack enhancements, bug fixes by &a.trasz;, updated
iSCSI stack enhancements and bug fixes by &a.trasz;, and updated
<tt>vt(4)</tt> system console by &a.ray;. A more detailed
project update for each of the above projects can be found
within this quarterly status report.</p>
@ -1761,9 +1761,9 @@ device vt_efifb</pre>
<p>After finishing the 10.0-RELEASE, Foundation system
administrator and release engineer &a.gjb; began work on
adding support for &os;/arm image builds as part of the
release build process. As result of this work, &os;/arm
release build process. As a result of this work, &os;/arm
images are produced as part of the weekly development snapshot
builds, and available from any of the &os; FTP mirrors.
builds, and are available from any of the &os; FTP mirrors.
Supported kernel configurations currently include
<tt>BEAGLEBONE</tt>, <tt>RPI-B</tt>, <tt>PANDABOARD</tt>,
<tt>WANDBOARD-QUAD</tt>, and <tt>ZEDBOARD</tt>.</p>
@ -1797,18 +1797,18 @@ device vt_efifb</pre>
</links>
<body>
<p>LLDB is the debugger project associated with
Clang/LLVM. It supports Mac OS X, Linux, and &os; 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.</p>
<p>LLDB is the debugger project associated with Clang/LLVM. It
supports the Mac OS X, Linux, and &os; 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.</p>
<p>The majority of work since the last status update has been on
bugfixes and implementation of the remaining functionality
missing on &os;. 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:</p>
missing on &os;. 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:</p>
<ul>
<li>Improvements to the remote GDB protocol client.</li>
@ -1924,9 +1924,9 @@ device vt_efifb</pre>
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 the reference.</p>
driver as a reference.</p>
<p>SDIO card detection and initialization already work, most
<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
@ -2105,53 +2105,51 @@ device vt_efifb</pre>
Now both the 9.x and 10.x branches share the same support for
Intel and AMD GPUs.</p>
<p>The next big tasks are the updates of the DRM generic code
and the <tt>i915</tt> 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.</p>
<p>The next big tasks are the updates of the DRM generic code and
the <tt>i915</tt> 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.</p>
<p>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
<q>Heads up</q> mail will be posted to the
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 <q>Heads up</q> mail will be posted to the
<tt>freebsd-x11</tt> mailing-list when this update goes
live.</p>
<p>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/<tt>libc++</tt>.</p>
<p>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/<tt>libc++</tt>.</p>
<p>We are preparing an alternate <tt>pkg(8)</tt> repository with
packages built with <tt>WITH_NEW_XORG</tt>. The goal is to
ease the usage of the KMS drivers and move forward with the
graphics stack updates. The main <tt>pkg(8)</tt> repository
will still use the default setting (<tt>WITH_NEW_XORG</tt> set
on <tt>head</tt>, but not on the <tt>stable</tt>
branches).</p>
packages built with <tt>WITH_NEW_XORG</tt>. The goal is to ease
the usage of the KMS drivers and move forward with the graphics
stack updates. The main <tt>pkg(8)</tt> repository will still
use the default setting (<tt>WITH_NEW_XORG</tt> set on
<tt>head</tt>, but not on the <tt>stable</tt> branches).</p>
<p>This will pave the way to <tt>WITH_NEW_XORG</tt> deprecation
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. &os; 9.3 and 10.1
will be fully equipped to work with the newer stack.
Unfortunately, &os; 8.x misses the required kernel DRM
infrastructure: supporting X.Org here cripples progress on the
graphics stack and, once <tt>WITH_NEW_XORG</tt> 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.</p>
<p>This will pave the way to the deprecation
of<tt>WITH_NEW_XORG</tt> 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. &os; 9.3 and 10.1 will be fully equipped to work
with the newer stack. Unfortunately, &os; 8.x misses the
required kernel DRM infrastructure: supporting X.Org here
cripples progress on the graphics stack and, once
<tt>WITH_NEW_XORG</tt> 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.</p>
</body>
<help>
@ -2198,10 +2196,10 @@ device vt_efifb</pre>
</links>
<body>
<p>The &os; Port Management Team is to ensure that the &os;
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
<p>The role of the &os; Port Management Team is to ensure that the
&os; 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.</p>
<p>The ports tree slowly approaches the 25,000 ports threshold,
@ -2217,18 +2215,18 @@ device vt_efifb</pre>
&a.antoine;.</p>
<p>Commencing March 1, the second intake of
<tt>portmgr-lurkers</tt> started active duty on
<tt>portmgr</tt> for a four month duration. The next two
candidates are &a.danfe; and &a.culot;.</p>
<tt>portmgr-lurkers</tt> started active duty on <tt>portmgr</tt>
for a four month duration. The next two candidates are
&a.danfe; and &a.culot;.</p>
<p>This quarter also saw the release of the first quarterly
branch, namely <tt>2014Q1</tt>. 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 <tt>head</tt>.</p>
related to security fixes as well as packaging and runtime fixes
being backported from <tt>head</tt>.</p>
<p>Ongoing maintenance goes into redports.org, including QAT
runs and ports and security updates.</p>
<p>Ongoing maintenance goes into redports.org, including QAT runs
and ports and security updates.</p>
</body>
<help>
@ -2321,7 +2319,7 @@ device vt_efifb</pre>
<body>
<p>The &os; Postmaster Team is responsible for mail being
correctly delivered to the committers' email address, ensuring
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.</p>
@ -2375,16 +2373,17 @@ device vt_efifb</pre>
<p>The first quarter of 2014 was very active for the Core Team.
&a.jhb; and &a.theraven; kept coordinating the work required
for providing a newer version of X.Org for 9.x and 10.x
systems. Now, after that <tt>vt(4)</tt>, a successor to
systems. Now that <tt>vt(4)</tt>, a successor to
<tt>syscons(4)</tt> that offers a KMS-enabled console, has
been merged to both <tt>stable/9</tt> and <tt>stable/10</tt>,
an alternative <tt>pkg(8)</tt> repository is in preparation
for wider testing. In addition to that, &a.jhb; published the
for wider testing of <tt>vt(4)</tt> and the new X.Org version.
In addition to that, &a.jhb; published the
policy on licenses for new files and files with non-standard
licenses. Thanks to the efforts of &a.gavin;, &os; has again
made it into the Google Summer of Code program, for the tenth
time now. &a.theraven; reported that both <tt>libc++</tt> and
<tt>libstdc++</tt> can be now built as all the
time. &a.theraven; reported that both <tt>libc++</tt> and
<tt>libstdc++</tt> can now be built, as all of the
standards-compliant implementations of the required numerical
functions have been added.</p>
@ -2407,7 +2406,7 @@ device vt_efifb</pre>
achieved by increasing the value of <tt>__FreeBSD_version</tt>
on each fix, therefore the corresponding discussion concluded
in freezing the ABI note tag for releases in order to keep the
size of the binary patches for <tt>freebsd-update(8)</tt> low.
size of binary patches for <tt>freebsd-update(8)</tt> low.
A related Errata Notice is about to be published soon.</p>
<p>Only a single commit bit was taken for safekeeping.
@ -2459,7 +2458,7 @@ device vt_efifb</pre>
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.</p>
to operate it. This is the ZFSguru style.</p>
<p>New system versions have been released, based on &os; 9.2,
10.0, and <tt>head</tt>. The experimental <tt>head</tt>
@ -2481,7 +2480,7 @@ device vt_efifb</pre>
</body>
<help>
<task>ZFSguru beta10 will increase compatibility of new added
<task>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.</task>
@ -2500,9 +2499,9 @@ device vt_efifb</pre>
<task>New website with new forum and new login system.</task>
<task>Developer website with GitLab setup, allowing bugreports,
<task>Developer website with GitLab setup, allowing bug reports,
code contributions, wiki, and wall messages. Note that GitLab
has also been provided as ZFSguru service, for those
has also been provided as a ZFSguru service, for those
interested in trying GitLab.</task>
</help>
</project>
@ -2559,7 +2558,7 @@ device vt_efifb</pre>
<body>
<p>bhyve is a Type-1 hypervisor that runs on the &os; platform.
It currently only runs &os; (9.x or later) and Linux guests,
It currently only runs &os; (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 &os; 10.0-RELEASE.
@ -2577,8 +2576,8 @@ device vt_efifb</pre>
<li>Graceful shutdown via ACPI on SIGTERM</li>
<li>Fix issue with virtio-blk devices on Linux guests with
more than 4GB of ram</li>
<li>Fix an issue with virtio-blk devices on Linux guests with
more than 4GB of RAM</li>
<li>Increase the block-layer backend maximum requests to match
AHCI command queue depth</li>