Date: Fri, 22 Jul 2016 05:19:45 +0000 (UTC) From: Benjamin Kaduk <bjk@FreeBSD.org> To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r49144 - head/en_US.ISO8859-1/htdocs/news/status Message-ID: <201607220519.u6M5JjIP023479@repo.freebsd.org>
next in thread | raw e-mail | index | archive | help
Author: bjk Date: Fri Jul 22 05:19:45 2016 New Revision: 49144 URL: https://svnweb.freebsd.org/changeset/doc/49144 Log: Make an editing pass through the 2016Q2 report Modified: head/en_US.ISO8859-1/htdocs/news/status/report-2016-04-2016-06.xml Modified: head/en_US.ISO8859-1/htdocs/news/status/report-2016-04-2016-06.xml ============================================================================== --- head/en_US.ISO8859-1/htdocs/news/status/report-2016-04-2016-06.xml Fri Jul 22 00:03:44 2016 (r49143) +++ head/en_US.ISO8859-1/htdocs/news/status/report-2016-04-2016-06.xml Fri Jul 22 05:19:45 2016 (r49144) @@ -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; 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 "beta" 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> + "not DRI2 capable". 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–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 & Packages" component as that is the easiest - starting point. Other categories like "Base System" require + "Ports & Packages" component as that is the easiest + starting point. Other categories like "Base System" 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 "ensure that an issue is summarized, + classified, and assigned to appropriate people", 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 "track the issue through its entire life to + resolution", 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, "patch" and + "patch-ready", 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201607220519.u6M5JjIP023479>