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

Make an editing pass through the 2016Q2 report

Browse source
This commit is contained in:
Benjamin Kaduk 2016-07-22 05:19:45 +00:00
parent bc7e8f3800
commit 6f23ec186d
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/head/; revision=49144
1 changed files with 172 additions and 160 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

332
en_US.ISO8859-1/htdocs/news/status/report-2016-04-2016-06.xml
View file

@ -97,8 +97,8 @@
<p>The &os; Release Engineering Team completed the 10.3-RELEASE
cycle late April, led by &a.marius;. The release was one week
behind the original schedule, to accommodate for a few last
minute critical issues that were essential to include in the
behind the original schedule, to accommodate for a few
last-minute critical issues that were essential to include in the
final release.</p>
<p>The &os;&nbsp;11.0-RELEASE cycle started late May, one month
@ -106,10 +106,10 @@
to accommodate for packaging the &os; base system with the
<tt>pkg(8)</tt> utility. However, as work on this progressed,
it became apparent that there were too many outstanding
issues. As a result, packaged base will be a "beta" feature
issues. As a result, packaged base will be a &quot;beta&quot; feature
for 11.0-RELEASE, with the goal of promoting it to a
first-class feature in 11.1-RELEASE, with additional
provisions to ensure a seamless transition for earlier
first-class feature in 11.1-RELEASE. It is expected that
provisions will be made to ensure a seamless transition from older
supported releases.</p>
<p>Despite the fact that packaged base is not going to be a
@ -120,7 +120,7 @@
</body>
<sponsor>
The &os; Foundation
The &os; Foundation
</sponsor>
</project>
@ -144,10 +144,10 @@
come to switch to 4.2.</p>
<p>While there is ongoing progress to remove Rails 3.2 from
the ports tree, there are some major updates blocking this
process. The most recent blocker was the outstanding update
of <tt>www/redmine</tt> from 2.6 to 3.2. This has completed
successfully, so we can now move on.</p>
the ports tree, there are some ports for which this is a major
update that block the overall process. The most recent blocker
was the outstanding update of <tt>www/redmine</tt> from 2.6 to
3.2. This has completed successfully, so we can now move on.</p>
<p>To help with porting or testing, feel free to contact me or
the <tt>ruby@FreeBSD.org</tt> mailing list.</p>
@ -180,26 +180,26 @@
<body>
<p>Allwinner SoCs are used in multiple hobbyist devboards and
single board computers. Recently, support for these SoCs
single-board computers. Recently, support for these SoCs
received many updates.</p>
<p>Theses tasks were completed during the second quarter of
2016:</p>
<ul>
<li>Switch to upstream DTS is complete</li>
<li>Switch to upstream DTS</li>
<li>A83T SoC support</li>
<li>H3 SoC support</li>
<li>Switch to new clock framework</li>
<li>Switch to the new clock framework</li>
<li>Convert A10 interrupt controller to INTRNG</li>
<li>Convert the A10 interrupt controller to <tt>INTRNG</tt></li>
<li>OHCI support</li>
<li>Generic ALLWINNER kernel config file</li>
<li>A generic <tt>ALLWINNER</tt> kernel config file</li>
<li>A20/A31 NMI support</li>
@ -213,8 +213,8 @@
<li>A83T Security ID support</li>
<li>Allwinner Gigabit Ethernet controller found in
H3/A83T/A64</li>
<li>Support for the Allwinner Gigabit Ethernet controller found
in H3/A83T/A64</li>
<li>USB OTG
<a href="https://reviews.freebsd.org/D5881">(in review)</a></li>
@ -267,10 +267,10 @@
</contact>
<body>
<p>Now that the process-shared locks are implemented for our
POSIX threads implementation library, <tt>libthr</tt>,
the only major lacking feature for POSIX compliance is robust
mutexes. Robust mutexes allow the application to detect, and
<p>Now that process-shared locks are implemented for our
POSIX threads implementation, <tt>libthr</tt>,
the only major feature lacking for POSIX compliance is robust
mutexes. Robust mutexes allow applications to detect, and
theoretically, recover from crashes which occur while
modifying the shared state. The supported model is to protect
shared state by a <tt>pthread_mutex</tt>, and the crash is
@ -284,7 +284,7 @@
recover from failures. The <tt>pthread_mutex_lock()</tt>
function may return new error <tt>EOWNERDEAD</tt>, which
indicates that the previous owner of the lock terminated while
still owning the lock. Despite returning the non-zero value,
still owning the lock. Despite returning this non-zero value,
the lock is granted to the caller. In the simplest form, an
application may detect the error and refuse to operate until
the persistent shared data is recovered, such as by manual
@ -299,22 +299,22 @@
<p>It is curious but not unexpected that this interface is not
used widely. The only real-life application which utilizes it
is Samba. Using Samba with an updated FreeBSD base uncovered
minor bugs both in the FreeBSD robustness implementation, and
is Samba. Using Samba with an updated &os; base uncovered
minor bugs both in the &os; robust mutex implementation, and
in Samba itself.</p>
<p>It is believed that <tt>libthr</tt> in FreeBSD 11 is
POSIX-compliant for large features. Further work is planned
to look at the lock structures inlining to remove overhead
and improve performance of the library.</p>
<p>It is believed that <tt>libthr</tt> in &os; 11 is
POSIX-compliant for major features. Further work is planned
to look at inlining the lock structures to remove overhead
and improve the performance of the library.</p>
<p>Most of the implementation of the robustness feature
consisted of making small changes in the lock and unlock
paths, both in <tt>libthr</tt> and in <tt>kern_umtx.c</tt>.
This literally required reading all of the code dealing with
mutexes and conditional variables, which was something I
mutexes and condition variables, which was something I
wanted to help future developers with. In the end, with the
help of Ed Maste, the man pages for <tt>umtx(2)</tt> and all
help of Ed Maste, man pages for <tt>umtx(2)</tt> and all
<tt>thr*(2)</tt> syscalls were written and added to the base
system's documentation set.
</p>
@ -329,7 +329,7 @@
</project>
<project cat='proj'>
<title>EFI Refactoring, GELI Support</title>
<title>EFI Refactoring and GELI Support</title>
<contact>
<person>
@ -357,16 +357,17 @@
too much effort.</p>
<p>Both <tt>boot1</tt> and <tt>loader</tt> have been refactored
to talk through the <tt>EFI_SIMPLE_FILE_SYSTEM</tt> interface.
In <tt>loader</tt>, this is accomplished with a dummy
to utilize the <tt>EFI_SIMPLE_FILE_SYSTEM</tt> interface.
In the loader, this is accomplished with a dummy
filesystem driver that is just a translation layer between the
<tt>loader</tt> filesystem interface and
loader filesystem interface and
<tt>EFI_SIMPLE_FILE_SYSTEM</tt>. A reverse translation layer
allows the existing filesystem drivers to function as EFI
drivers.</p>
<p>The EFI refactoring by itself exists in
<a href="https://github.com/emc2/freebsd/tree/efize">this branch</a>.</p>
<p>The EFI refactoring by itself exists in a
<a href="https://github.com/emc2/freebsd/tree/efize">branch
on github</a>.</p>
<p>Additionally, GELI support has been added using the EFI
refactoring. This allows booting from a GELI-encrypted
@ -376,7 +377,7 @@
framework, which allows injection of keys directly into a
loaded kernel, without the need to pass them through
arguments or environment variables. This patch only uses the
intake buffer for EFI GELI support as legacy BIOS GELI support
intake buffer for EFI GELI support, as legacy BIOS GELI support
still uses environment variables.</p>
<p>EFI GELI support depends on the
@ -404,7 +405,7 @@
</li>
<li>
<p>Install an EFI shell on the ESP.</p>
<p>Install an EFI shell on the EFI System Partition (ESP).</p>
</li>
<li>
@ -439,7 +440,7 @@
<li>
<p>Try switching over to an encrypted main partition once
everything else has worked.</p>
everything else is working.</p>
</li>
</ol>
</body>
@ -447,9 +448,8 @@
<help>
<task>Testing is needed.</task>
<task>Code will need review and some <tt>style(9)</tt>
normalization must occur before this code goes into
FreeBSD.</task>
<task>The code will need review, and some <tt>style(9)</tt>
normalization must occur before it goes into &os;.</task>
</help>
</project>
@ -475,7 +475,7 @@
</contact>
<body>
<p>The port has been updated to GDB 7.11.1.</p>
<p>The <tt>devel/gdb</tt> port has been updated to GDB 7.11.1.</p>
<p>Support for system call catchpoints has been committed
upstream. Support for examining ELF auxiliary vector data via
@ -484,12 +484,12 @@
</body>
<help>
<task>Figure out why the <tt>powerpc kgdb</tt> targets are not
<task>Figure out why the <tt>powerpc</tt> <tt>kgdb</tt> targets are not
able to unwind the stack past the initial frame.</task>
<task>Add support for more platforms, such as <tt>arm</tt>,
<tt>mips</tt>, and <tt>aarch64</tt>, to upstream gdb for both
userland and kgdb.</task>
<tt>mips</tt>, and <tt>aarch64</tt>, to upstream <tt>gdb</tt> for both
userland and <tt>kgdb</tt>.</task>
<task>Add support for debugging <tt>powerpc</tt> vector
registers.</task>
@ -516,11 +516,11 @@
</contact>
<links>
<url href="https://svnweb.freebsd.org/base/projects/vnet/">Projects workspace (all merged to head now).</url>
<url href="https://svnweb.freebsd.org/base/projects/vnet/">Project workspace (all merged to head now).</url>
</links>
<body>
<p>VIMAGE is a virtualization framework on top of FreeBSD jails
<p>VIMAGE is a virtualization framework on top of &os; jails
that was introduced to the kernel about eight years ago with
the <tt>vnet</tt> virtualized network stack.</p>
@ -533,8 +533,9 @@
<p>The <tt>vnet</tt> teardown has been changed to be from top to
bottom, trying to tear down layer by layer. This is
preferable to removing interfaces first and then cleaning
everything up, as no more packets could flow. Along with this
work, various parts with potential memory leaks were plugged.
everything up, as no more packets could flow once the
interfaces are gone. Along with this
work, various paths with potential memory leaks were plugged.
Lastly, <tt>vnet</tt> support was added to formerly
unvirtualized components, such as the <tt>pf</tt> and
<tt>ipfilter</tt> firewalls and some virtual interfaces.</p>
@ -543,7 +544,7 @@
<sponsor>The FreeBSD Foundation</sponsor>
<help>
<task>Please test FreeBSD 11.0-ALPHA6 or later. When reporting
<task>Please test &os; 11.0-ALPHA6 or later. When reporting
a problem, use the <tt>vimage</tt> keyword in the FreeBSD bug
tracker.</task>
</help>
@ -569,9 +570,9 @@
<body>
<p>Half a year ago, I started a promotion campaign to improve
support for fetching ports via IPv6. Research performed in
December, 2015 showed that 10,308 of 25,522 ports are not
fetchable when using IPv6-only as these ports ignore the <a
href="distcache.freebsd.org">FreeBSD.org pkg mirror</a>.</p>
December 2015 showed that 10,308 of 25,522 ports were not
fetchable when using IPv6-only, as these ports ignore the <a
href="distcache.freebsd.org">FreeBSD.org <tt>pkg</tt> mirror</a>.</p>
<p>As a result of the campaign, the following servers now
successfully support IPv6:</p>
@ -590,7 +591,7 @@
<p>This enables 711 more ports to be fetched via IPv6.</p>
<p>I would like to thank Wolfgang Zenker who is very active in
<p>I would like to thank Wolfgang Zenker, who is very active in
supporting the adoption of IPv6. During the latest RIPE
meeting, he brought up the topic of non-support of IPv6
being a hindrance to business. I am hopeful that his talk
@ -637,15 +638,15 @@
</contact>
<links>
<url href="https://wiki.freebsd.org/HyperV">FreeBSD Virtual Machines on Microsoft Hyper-V</url>
<url href="https://technet.microsoft.com/en-us/library/dn531030.aspx">Supported Linux and FreeBSD virtual machines for Hyper-V on Windows</url>
<url href="https://wiki.freebsd.org/HyperV">&os; Virtual Machines on Microsoft Hyper-V</url>
<url href="https://technet.microsoft.com/en-us/library/dn531030.aspx">Supported Linux and &os; virtual machines for Hyper-V on Windows</url>
</links>
<body>
<p>During BSDCan 2016, Microsoft <a
href="https://azure.microsoft.com/en-us/blog/freebsd-now-available-in-azure-marketplace/">announced</a>
the global availability of FreeBSD 10.3 images in Azure.
There are many FreeBSD-based Azure virtual appliances in the
the global availability of &os; 10.3 images in Azure.
There are many &os;-based Azure virtual appliances in the
Azure Marketplace, including Citrix Systems' NetScaler and
Netgate's pfSense. Microsoft also made an in-depth technical
presentation to introduce how the performance of the Hyper-V
@ -659,11 +660,11 @@
performance of Hyper-V network and storage device drivers.
Work is ongoing to replace the internal data structure in the
LRO kernel API from a singly-linked list to a double-linked
list, to speed up the LRO lookup by hash table, and to compare
list, to speed up the LRO lookup by hash table, and to evaluate
the performance with <tt>tcp_lro_queue_mbuf()</tt>.</p>
<p>The handling of SCSI inquiry in the Hyper-V storage driver is
enhanced to make sure disk hotplug and <tt>smartctl(8)</tt>
enhanced to make sure that disk hotplug and <tt>smartctl(8)</tt>
work reliably. Refer to <a
href="https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210425">PR 210425</a>
and <a
@ -698,12 +699,12 @@
<url href="http://ceph.com">Ceph main site</url>
<url href="https://github.com/ceph/ceph">Main repository</url>
<url href="https://github.com/wjwithagen/ceph">My Fork </url>
<url href="https://github.com/ceph/ceph/pull/7573">The git PULL with all changes</url>
<url href="https://github.com/ceph/ceph/pull/7573">Pull request with &os;-specific changes to Ceph</url>
</links>
<body>
<p>Ceph is a distributed object store and file system designed
to provide excellent performance, reliability, and
<p>Ceph is a distributed object store and filesystem designed
to provide excellent performance, reliability, and
scalability. It provides the following features:</p>
<ol>
@ -716,38 +717,38 @@
access to block device images that are striped and
replicated across the entire storage cluster.</li>
<li>File System: Ceph provides a POSIX-compliant network file
system that aims for high performance, large data storage,
<li>File System: Ceph provides a POSIX-compliant network
filesystem that aims for high performance, large data storage,
and maximum compatibility with legacy applications.</li>
</ol>
<p>I started looking into Ceph as using HAST with CARP and
<p>I started looking into Ceph because using HAST with CARP and
<tt>ggate</tt> did not meet my requirements. My primary goal
with Ceph is to run a storage cluster of ZFS storage nodes
where the clients run bhyve on RBD disks stored in Ceph.</p>
where the clients run <tt>bhyve</tt> on RBD disks stored in Ceph.</p>
<p>The &os; build process can build most of the tools in
Ceph. However, the RBD-dependent items do not work since
Ceph. However, the RBD-dependent items do not work, since
&os; does not yet provide RBD support.</p>
<p>Since the last quarterly report, the following progress was
made:</p>
<ol>
<li>The changeover from using CMake to Automake results in a
<li>Switching to using CMake from Automake results in a
much cleaner development environment and better test output.
The changes can be found in the
<tt>wip-wjw-freebsd-cmake</tt> branch.</li>
<li>Throttling code has been overhauled to prevent live locks.
<li>The throttling code has been overhauled to prevent live locks.
These mainly occur on &os; but also manifest on Linux.</li>
<li>Fixed a few more tests. On one occasion, I was able to
complete the full test set without errors.</li>
<li>A few more tests were fixed. On one occasion, I was able to
complete the full test suite without errors.</li>
</ol>
<p>11-CURRENT is used to compile and build test Ceph. The
Clang toolset needs to be at least version 3.7 as Clang 3.4
Clang toolset needs to be at least version 3.7, as Clang 3.4
does not have all of the capabilities required to compile
everything.</p>
@ -755,7 +756,7 @@
<ul>
<li>
<p>Install <tt>bash</tt> and link it in <tt>/bin</tt>
<p>Install <tt>bash</tt> and link to it in <tt>/bin</tt>
(requires root privileges):</p>
<p><tt>sudo pkg install bash</tt></p>
@ -787,33 +788,33 @@
<ul>
<li>RBD: Rados Block Devices are currently implemented in the
Linux kernel but there used to be a userspace
Linux kernel, but there used to be a userspace
implementation. It is possible that <tt>ggated</tt> could
be used as a template since it provides some of the same
be used as a template, since it provides some of the same
functionality and it has a userspace counterpart.</li>
<li>BlueStore: &os; and Linux have a different AIO API which
needs to be made compatible. There has been some
needs to be bridged. There has been some
discussion about <tt>aio_cancel</tt> not working for all
device types in &os;.</li>
<li>CephFS: Cython tries to access an internal field in dirent
which does not compile.</li>
<li>CephFS: Cython tries to access an internal field in
<tt> struct dirent</tt>, which fails to compile.</li>
<li>Tests that verify the correct working of the above are
also excluded from the testset.</li>
<li>Tests that verify the correct functionality of these are
also excluded from the test suite.</li>
</ul>
<p>Tests Not Yet Included:</p>
<ul>
<li><tt>ceph-detect-init/run-tox.sh</tt>: the current
implementation does not know anything about &os;
<tt>rc-init</tt>.</li>
implementation does not know anything about &os;'s
<tt>rc</tt> system.</li>
<li>Tests that make use of <tt>nosestests</tt> do not really
work since <tt>nostests</tt> is not in <tt>/usr/bin</tt>,
and calling <tt>/usr/bin/env/nosetests</tt> does not work on
<li>Tests that make use of <tt>nosetests</tt> do not really
work since <tt>nosetests</tt> is not in <tt>/usr/bin</tt>,
and calling <tt>/usr/bin/env nosetests</tt> does not work on
&os;.</li>
<li><tt>test/pybind/test_ceph_argparse.py</tt></li>
@ -823,13 +824,13 @@
</body>
<help>
<task>The current and foremost task it to get the test set to
<task>The current and foremost task it to get the test suite to
complete without errors.</task>
<task>Build an automated test platform that will build
<tt>ceph/master</tt> on &os; and report the results back to
the Ceph developers. This will increase the maintainability
of the &os; side of things as developers are signaled that
of the &os; side of things, as developers are signaled that
they are using Linux-isms that will not compile or run on
&os;. Ceph has several projects that support this: Jenkins,
teuthology, and palpito. But even a
@ -845,7 +846,7 @@
Device).</task>
<task>Investigate if an in-kernel RBD device could be developed
ala <tt>ggate</tt>.</task>
akin to <tt>ggate</tt>.</task>
<task>Investigate the keystore which currently prevents the
building of Cephfs and some other parts.</task>
@ -890,7 +891,7 @@
&os;, which is quite a commendation.</p>
<p>Current work aims to fix the open problems, get the latest
major version into the port, and create the documentation for
major version into the port, and create documentation for
the update progress.</p>
</body>
</project>
@ -931,107 +932,117 @@
<p><tt>proccontrol -m (trace|aslr) [-q] [-s (enable|disable)]
[-p pid | command]</tt></p>
<p><tt>-m</tt> (specifies trace mode to control debugger
<p>with possible arguments</p>
<p><tt>-m</tt> (specifies the trace mode to control debugger
attachments)</p>
<p><tt>-q</tt> (queries the state of the specified mode for the
process with the PID specified by <tt>-p</tt> option)</p>
process with the PID specified by the <tt>-p</tt> option)</p>
<p><tt>-e</tt> (toggles the feature on or off for the given
process or itself)</p>
<p>If the command is specified, it inherits the applied
<p>If a command is specified, it inherits the applied
settings from <tt>proccontrol</tt>. For instance, to start a
build of a program with ASLR disabled, use
<tt>proccontrol -m aslr -s disable make</tt>.</p>
<p>The ports exp run was done with ASLR tuned up to the most
<p>A ports exp-run was done with ASLR tuned up to the most
aggressive settings. The results can be found in <a
href="https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=208580">PR 208580</a>.</p>
<p>Case study: Lisp</p>
<p>SBCL is an interesting case which illustrates several points.
It is much smaller than JDK, and its build system is easier to
work with. The code provides a very non C-ish language
runtime which utilizes a lot of corner cases and non-standard
uses of VM, at least from the point of view of a typical C
work with. The code provides a very non C-like language
runtime which utilizes a lot of corner cases and makes non-standard
uses of the VM system, at least from the point of view of a typical C
programmer.</p>
<p>SBCL compiles Lisp forms into the machine native code and
manages its own arena for objects. The precompiled Lisp
runtime is mapped from the <tt>core</tt> file. SBCL relies on
runtime is mapped from a <tt>core</tt> file. SBCL relies on
the operating system's C runtime for the initial load of Lisp,
and needs a functional <tt>libc</tt> to issue many system
calls, including syscalls, as well as the dynamic loader. The
end result is that there are unfixed <tt>mmap(2)</tt> calls
during both startup and runtime, interfering with the
<tt>MAP_FIXED mmaps</tt>. The core file loading and arenas
are hard-coded to exist at fixed addresses.</p>
during both startup and runtime, interfering with other
<tt>MAP_FIXED mmaps</tt>. The loading of the core file
and the private arenas are hard-coded to exist at fixed
addresses.</p>
<p>This happens to work on the default address map, which is not
changed often, so the SBCL choices of the base addresses
evolved to work. But any significant distortion of the
standard map results in <tt>SBCL mmap(MAP_FIXED)</tt> requests
to override memory from other allocators.</p>
attempting to override memory from other allocators.</p>
<p>&os; uses the <tt>MAP_EXCL</tt> flag to <tt>mmap(2)</tt>,
which must be used in <tt>MAP_FIXED|MAP_EXCL</tt> form to
cause <tt>mmap(2)</tt> failure if the requested range is
which must be used in the <tt>MAP_FIXED|MAP_EXCL</tt> form to
cause <tt>mmap(2)</tt> to fail if the requested range is
already used. I tried to force <tt>MAP_FIXED</tt> requests
from SBCL to implicitely set <tt>MAP_EXCL</tt>, but this did
from SBCL to implicitly set <tt>MAP_EXCL</tt>, but this did
not go well since SBCL sometimes pre-allocates regions for
later use with <tt>MAP_FIXED</tt>. So, <tt>MAP_EXCL</tt>
mappings failed, dumping the process into <tt>ldb</tt>.</p>
<p>On Linux, if a kernel is detected in AS-randomization mode,
the initial SBCL runtime sets personality to non-random and
<p>On Linux, if it is detected that the kernel is in AS-randomization mode,
the initial SBCL runtime sets its personality to non-random and
re-execs. This might be a solution for &os; as well, after
the ASLR patch is committed, so that the <tt>procctl(2)</tt>
knob is officially available.</p>
<p>SBCL still has issues on Linux, even with re-exec, when
more aggressive randomization from PaX patch is applied, as
more aggressive randomization from the PaX patch is applied, as
seen in <a
href="https://bugs.launchpad.net/sbcl/+bug/1523213">bug
1523213</a>.</p>
<p>Case study: Emacs</p>
<p>The Emacs build procedure involves loading the
<tt>temacs</tt> image with the compiled Emacs Lisp files and
then dumping the memory to recreate the image with the
preloaded content, in order to shrink the start time.</p>
then dumping its memory to create an image with the content
preloaded, in order to reduce startup time.</p>
<p>Recent Emacs sources seem to generally avoid
<tt>MAP_FIXED</tt>, except in some situations. When Emacs
does use the flag, it carefully checks that the selected
region is not busy. In fact, Emacs would benefit from
region is not busy. In fact, Emacs would benefit from using
<tt>MAP_EXCL</tt>.</p>
<p>I tried several runs of building Emacs and running the dumped
binary, but was not able to reproduce the issue. It seems
binary, but was not able to reproduce any issues. It seems
that the code improved enough to tolerate ASLR both in Linux
and NetBSD without turning it off.</p>
<p>In my opinion, it is not reasonable to fight the issues in
the kernel as most of it is not fixable from the kernel side.
The <tt>procctl(2)</tt> interface and <tt>proccontrol(1)</tt>
utilities provide the override when needed, but are not
utilities provide an override when needed, but are not
automated.</p>
<p>Conclusions</p>
<p>The set of ports which cannot be built with ASLR turned on
should be limited but fluid. However, exp-runs may not
reliably uncover all problems due to randomization, as seen in
the Emacs example. In the route to enable ASLR by default in
non-aggressive settings, the ports framework should provide an
the Emacs example. In the route to enable ASLR by default (with
non-aggressive settings), the ports framework should provide an
option like <tt>ASLR_UNSAFE=yes</tt> which spawns
<tt>proccontrol -m aslr -s disable make</tt> for the build
stages of the unsafe port. Users would still need to be aware
of <tt>proccontrol(1)</tt> in order to run the resulting
binary.</p>
binary or wrapper scripts provided to do so.</p>
<p>A recommended approach is a flag in the ELF binary to mark
it as not compatible with non-standard AS layouts. This frees
users from having to use <tt>proccontrol(1)</tt>, but still
requires patching and upstreaming. This approach is also
useful outside the context of ASLR. However, the
requires patching the application's build process and
upstreaming the changes. This approach is also
useful outside the context of ASLR. However, that
mechanism is not yet ready, and developing it is a larger work
than ASLR itself.</p>
</body>
@ -1062,7 +1073,7 @@
<url href="http://wiki.FreeBSD.org/Graphics">Graphics Stack Roadmap and Supported Hardware Matrix</url>
<url href="https://github.com/FreeBSD/freebsd-ports-graphics">Ports Development Repository</url>
<url href="https://github.com/FreeBSDDesktop/freebsd-base-graphics/tree/drm-next-4.6">DRM 4.6 Development Repository</url>
<url href="https://wiki.freebsd.org/SummerOfCodeIdeas#Devices_management:_link_.2Fdev_entries_to_sysctl_nodes">GSoC 2016: link /dev entries to sysctl nodes</url>
<url href="https://wiki.freebsd.org/SummerOfCodeIdeas#Devices_management:_link_.2Fdev_entries_to_sysctl_nodes">GSoC 2016: link <tt>/dev</tt> entries to sysctl nodes</url>
<url href="https://wiki.freebsd.org/SummerOfCode2016/RethinkLibdevq">GSoC 2016: Redesign libdevq </url>
<url href="http://planet.freebsd.org/graphics">Graphics Team Blog</url>
</links>
@ -1075,7 +1086,8 @@
<p>The GSoC project about being able to connect a <tt>/dev</tt>
entry to <tt>sysctl</tt> nodes is making progress. After some
fruitful discussons on the <a
href="https://lists.freebsd.org/mailman/listinfo/freebsd-arch">freebsd-arch@ mailing-list</a>,
href="https://lists.freebsd.org/mailman/listinfo/freebsd-arch">freebsd-arch@
mailing-list</a>,
Kiloreux finished the design and is now implementing the
solution. The GSoC project on <tt>libdevq</tt> was
abandoned.</p>
@ -1090,7 +1102,7 @@
<ul>
<li>There are instances of visual artifacts that appear with
varying frequency, depending on workload. Of particular
note is lack of redraw when a Qt5 window is partially
note is the lack of redraw when a Qt5 window is partially
covered by a menu and then uncovered.</li>
<li>WebGL demos will sometimes fail due to a recoverable
@ -1104,11 +1116,11 @@
issues, along with others, by updating Linux support to the
point where the Intel GPU Tools work on &os;.</p>
<p>The Radeon AMD/ATI has been updated to GCN 1.0. This has
<p>The Radeon AMD/ATI driver has been updated to GCN 1.0. This has
only been tested on an R7 240. 2D-accelerated X works. Due
to apparent issues with user library support, X does not
recognize the KMS driver as being 3D-capable and reports it as
"not DRI2 capable". The OpenCL benchmark <tt>clpeak</tt>
&quot;not DRI2 capable&quot;. The OpenCL benchmark <tt>clpeak</tt>
fails in <tt>drm/ttm</tt>, so there may in fact be issues in
the underlying 3D support.</p>
@ -1131,7 +1143,7 @@
</body>
</project>
<project cat='team'>
<project cat='team'>
<title>&os; IRC Admin Team</title>
<contact>
@ -1215,10 +1227,10 @@
href="https://wiki.freebsd.org/IRC/Cloaks">IRC
Cloaks</a>.</li>
<li>Obtain a report on all nicknames and accounts with
<li>Obtained a report on all nicknames and accounts with
existing <tt>freebsd/*</tt> user cloaks.</li>
<li>Liaise with freenode staff on upcoming changes to freebsd
<li>Liaised with freenode staff on upcoming changes to freebsd
channels.</li>
</ul>
@ -1432,7 +1444,7 @@
<p>Another of Core's important functions is to ensure good
relations amongst developers. To that end, members of Core
provided oversight over the backing-out of disputed
<tt>blacklistd</tt> related patches to OpenSSH, and acted to
<tt>blacklistd</tt>-related patches to OpenSSH, and acted to
smooth over ruffled tempers.</p>
<p>This quarter saw the usual quota of gentle reminders to avoid
@ -1503,7 +1515,7 @@
</contact>
<body>
<p>Since the Triage Team was introduced in the October-December
<p>Since the Triage Team was introduced in the October&ndash;December
2015 report, it has been working on the following three major
aspects of issue triage:</p>
@ -1520,13 +1532,13 @@
</ul>
<p>Our efforts have almost exclusively focused on issues in the
"Ports &amp; Packages" component as that is the easiest
starting point. Other categories like "Base System" require
&quot;Ports &amp; Packages&quot; component as that is the easiest
starting point. Other categories like &quot;Base System&quot; require
more knowledge and experience with problem content and
workflow.</p>
<p>During this time, Rodrigo was inactive due to lack of
available time and Vladimir was unable to commit enough time
available time, and Vladimir was unable to commit enough time
during the first quarter of the year, but provided active
contribution during the second. It became obvious that the
Issue Triage Team must concentrate on additional recruitment
@ -1537,17 +1549,17 @@
Wiki page. A summary of those issues is given here:</p>
<ol>
<li>Issue triage, defined as "ensure an issue is summarized,
classified, and assigned to appropriate people", is too time
<li>Issue triage, defined as &quot;ensure that an issue is summarized,
classified, and assigned to appropriate people&quot;, is too time
consuming. Bugzilla automation through auto-assign helps,
but is insufficient. If the triage process is extended to
include "track the issue through its entire life to
resolution", the time and effort required grows
include &quot;track the issue through its entire life to
resolution&quot;, the time and effort required grows
exponentially. Fortunately, there are many things the
community can do, with minimum effort, that help greatly.
Part of the recruitment and education process is educating
users on how to properly treat their own issues and issues
they interact with in order to maximize the efficiency of
they interact with, in order to maximize the efficiency of
issue tracking and problem resolution.</li>
<li>Various timeouts are inadequate. For example, the
@ -1577,13 +1589,13 @@
track and quickly find issue categories and, more
importantly, their <strong>states</strong>. Another example
is ensuring that various flags and keywords are unambiguous
and well understood. For instance, "patch" and
"patch-ready", can often be misunderstood or
and well understood. For instance, &quot;patch&quot; and
&quot;patch-ready&quot;, can often be misunderstood or
misapplied.</li>
<li>Issue statistics are lacking and for the next quarter we
<li>Issue statistics are lacking, and for the next quarter we
intend to change that. Statistics help to provide insight
into potential bottlenecks and inform the priority of
into potential bottlenecks and inform the prioritization of
improvements to the issue tracker and workflows.</li>
</ol>
</body>
@ -1705,7 +1717,8 @@
the idea is that building the same binary, software package,
document, or other binary artifact twice from the same source
produces identical output. The <a
href="https://reproducible-builds.org/">reproducible-builds.org website</a>
href="https://reproducible-builds.org/">reproducible-builds.org
website</a>
provides background information and documentation on making
builds reproducible.</p>
@ -1724,7 +1737,7 @@
Ed investigated the state of build reproducibility
in the ports tree, and presented
<i>Reproducible Builds in &os;</i> at BSDCan 2016. With
some work in progress patches, over 80% of the &os; ports tree
some work-in-progress patches, over 80% of the &os; ports tree
builds reproducibly.</p>
<p>The Diffoscope tool performs in-depth comparison of files,
@ -1795,11 +1808,11 @@
<li>Qt Creator was updated to 3.4.0, 3.5.0, 3.5.1, 3.6.0,
4.0.0, 4.0.1, and 4.0.2.</li>
<li>Added the new port <tt>misc/qt5-examples</tt> for the
<li>A new port <tt>misc/qt5-examples</tt> was added for the
project examples provided by Qt. This makes Qt Creator more
functional.</li>
<li>Added the new port <tt>misc/qt5-doc</tt> for Qt's API
<li>A new port <tt>misc/qt5-doc</tt> was added for Qt's API
documentation, used by Qt Creator and other programs.</li>
<li>The base KDE4 ports were updated to 4.14.10.</li>
@ -1831,7 +1844,6 @@
<given>René</given>
<common>Ladan</common>
</name>
<email>portmgr-secretary@FreeBSD.org</email>
</person>
@ -1869,7 +1881,7 @@
made.</p>
<p>A lot of work was done on modernizing the infrastructure of
the Ports Tree, by introducing 6 new <tt>USES</tt>, one new
the Ports Tree, by introducing 6 new <tt>USES</tt> knobs, one new
keyword, and splitting out the larger targets of
<tt>bsd.port.mk</tt> into separate scripts. There were a
total of 42 exp-runs to validate these and other
@ -1889,7 +1901,7 @@
the package building infrastructure.</p>
<p>During BSDCan, <tt>mat</tt> worked on various items,
including updating the Porter's Handbook, and portmgr held a
including updating the Porter's Handbook, and portmgr held a
meeting to discuss various items.</p>
</body>
</project>
@ -1927,7 +1939,7 @@
integrate with <tt>intrng</tt>.</p>
<p>Busdma was updated to handle the cache. The updated code
assumes the device is non-coherent by default, unless the
assumes that devices are non-coherent by default, unless the
device driver marks the DMA tag as coherent when creating it.
The generic and ThunderX PCIe drivers have been updated to
create coherent mappings when the device tree marks the
@ -1935,37 +1947,37 @@
the sync operation where it was missing memory barriers.</p>
<p>A number of issues with <tt>hwpmc</tt> have been fixed. This
improves the stability of <tt>hwpmc</tt> on <tt>arm64</tt>
improves the stability of <tt>hwpmc</tt> on <tt>arm64</tt>,
with no known software issues. There is a single known issue
which seems to be hardware-related, however further testing is
which seems to be hardware-related, however, further testing is
required.</p>
<p><tt>NEW_PCIB</tt> has been enabled on <tt>arm64</tt>. This
includes handling the <tt>PCI_RES_BUS</tt> resource type.</p>
<p>Old interfaces replaced before 11 have been removed from the
<p>Old interfaces replaced before &os;-11 have been removed from the
<tt>arm64</tt> kernel and libraries. This includes support
for compatibility with <tt>libc</tt> from releases prior to
11. The <tt>brk</tt> and <tt>sbrk</tt> functions have also
11.0. The <tt>brk</tt> and <tt>sbrk</tt> functions have also
been removed. This allows a workaround for these functions in
the <tt>arm64</tt> C runtime to be removed.</p>
<p><tt>loader.efi</tt> has been updated to use an event timer to
implement its internal time function. This is needed as many
UEFI implementations do not handle The <tt>GetTime</tt>
runtime service method. This means <tt>loader.efi</tt> will
implement its internal time function. This is needed, as many
UEFI implementations do not handle the <tt>GetTime</tt>
runtime service method. This means that <tt>loader.efi</tt> will
now correctly count down before automatically booting.</p>
<p>Initial support for the ARM Juno reference platform has been
added. This hardware is common within ARM, and has been
useful for finding assumptions on cpuids. Booting on the Juno
required fixing the kernel to remove the assumption it is
required fixing the kernel to remove the assumption that it is
booting from CPU zero. This included assigning cpuids and
fixing assumptions within the <tt>GICv2</tt> driver that the
cpuid is the same as the <tt>GIC</tt> cpuid. &os; can now
boot on the 4 Cortex-A53 CPUs. Further investigation is
needed to track down why the boot fails when the 2 Cortex-A57
CPUs are enabled.</p>
boot on the 4 Cortex-A53 CPUs of the Juno board.
Further investigation is needed to track down why the boot
fails when the 2 Cortex-A57 CPUs are enabled.</p>
<p>Initial work has started on booting &os; on the Pine64 and
Raspberry Pi 3 boards. Both can boot to multiuser mode with