Date: Sun, 31 Jan 2016 21:51:40 +0000 (UTC) From: Warren Block <wblock@FreeBSD.org> To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r48132 - head/en_US.ISO8859-1/htdocs/news/status Message-ID: <201601312151.u0VLpeKR013447@repo.freebsd.org>
next in thread | raw e-mail | index | archive | help
Author: wblock Date: Sun Jan 31 21:51:40 2016 New Revision: 48132 URL: https://svnweb.freebsd.org/changeset/doc/48132 Log: Editing pass. Yes, I changed stuff. It got a bit weird with the time travel in the third act, and the whole car chase scene did not make sense. Modified: head/en_US.ISO8859-1/htdocs/news/status/report-2015-10-2015-12.xml Modified: head/en_US.ISO8859-1/htdocs/news/status/report-2015-10-2015-12.xml ============================================================================== --- head/en_US.ISO8859-1/htdocs/news/status/report-2015-10-2015-12.xml Sun Jan 31 16:30:18 2016 (r48131) +++ head/en_US.ISO8859-1/htdocs/news/status/report-2015-10-2015-12.xml Sun Jan 31 21:51:40 2016 (r48132) @@ -104,7 +104,7 @@ <p>LKL ("Linux Kernel as a Library") is a special "architecture" of the full Linux kernel that builds as a userspace library on various platforms, including &os;. One - application of such a library is using Linux's filesystem drivers + application of such a library is using Linux filesystem drivers to implement a FUSE backend.</p> <p>fusefs-lkl's <tt>lklfuse</tt> binary is such a FUSE @@ -112,14 +112,14 @@ <tt>BTRFS</tt> read-write, using the native drivers from Linux.</p> - <p>The <tt>sysutils/fusefs-lkl</tt> port may now be installed from + <p><tt>sysutils/fusefs-lkl</tt> can now be installed either from packages or ports, providing access to these filesystems on &os; via FUSE.</p> </body> </project> <project cat='doc'> - <title>Style(9) enhanced to allow C99 'bool'</title> + <title><tt>style(9)</tt> Enhanced to Allow C99 <tt>bool</tt></title> <contact> <person> @@ -146,7 +146,7 @@ <body> <p>Use of <tt>bool</tt> is now allowed. It was allowed - previously, as well, but now it's <em>really</em> allowed. Party + previously, as well, but now it is <em>really</em> allowed. Party like it's 1999!</p> </body> @@ -167,7 +167,7 @@ </project> <project cat='kern'> - <title>Sysctl enhancements</title> + <title><tt>sysctl</tt> Enhancements</title> <contact> <person> @@ -201,13 +201,13 @@ </links> <body> - <p> This quarter, support was added for fixed-width sysctls + <p>Support was added for fixed-width sysctls (signed and unsigned 8-bit, 16-bit, 32-bit, and 64-bit integers). The new KPIs are documented in the <tt>sysctl(9)</tt> manual page. The <tt>sysctl(8)</tt> command line tool supports all of the new types.</p> - <p><tt>sysctl(8)</tt> gained the '-t' flag, which prints sysctl type + <p><tt>sysctl(8)</tt> gained the <tt>-t</tt> flag, which prints sysctl type information (the original patch was submitted by Yoshihiro Ota). This support includes the newly added fixed-width types.</p> </body> @@ -218,7 +218,7 @@ </project> <project cat='kern'> - <title>ioat(4) driver enhancements</title> + <title><tt>ioat(4)</tt> Driver Enhancements</title> <contact> <person> @@ -240,8 +240,8 @@ engines built into some Intel Server/Storage platform CPUs.</p> - <p>This quarter, several enhancements were made to the driver. - The driver now avoids memory allocation in locked paths, which + <p>Several enhancements were made to the driver. + It now avoids memory allocation in locked paths, which should avoid deadlocking in memory pressure scenarios. Support for Broadwell-EP devices has been added. The "blockfill" operation and a non-contiguous 8 KB copy @@ -261,7 +261,7 @@ </project> <project cat='kern'> - <title>ntb_hw(4)/if_ntb(4) driver synced up to Linux</title> + <title><tt>ntb_hw(4)</tt>/<tt>if_ntb(4)</tt> Driver Synced up to Linux</title> <contact> <person> @@ -311,7 +311,7 @@ </project> <project cat='arch'> - <title>&os; on newer ARM boards</title> + <title>&os; on Newer ARM Boards</title> <contact> <person> @@ -337,9 +337,9 @@ </links> <body> - <p>This quarter, we made the changes necessary to support the + <p>We made the changes required to support the Amlogic Meson Ethernet controller on the Hardkernel ODROID-C1 - board which has an Amlogic aml8726-m8b SoC. The main effort + board, which has an Amlogic aml8726-m8b SoC. The main effort needed was to write a glue driver for the Ethernet controller — the Amlogic Meson Ethernet controller is compatible with Synopsys DesignWare 10/100/1000 Ethernet MAC @@ -387,7 +387,7 @@ </project> <project cat='doc'> - <title>"FreeBSD Mastery: Specialty Filesystems" early access version now available</title> + <title>"FreeBSD Mastery: Specialty Filesystems" Early Access Version Now Available</title> <contact> <person> @@ -413,7 +413,7 @@ NFSv4 ACLs, iSCSI, CIFS, and more.</p> <p>If you act really quickly, you can get the electronic early - access version at a 10% discount. You'll get the final ebook when + access version at a 10% discount. You will get the final ebook when it comes out as well. (This offer evaporates when the final version comes out.)</p> </body> @@ -437,10 +437,10 @@ </links> <body> - <p>The KGDB option is now on by default in the devel/gdb + <p>The KGDB option is now on by default in the <tt>devel/gdb</tt> port.</p> - <p>The changes to support cross-debugging of crashdumps in + <p>Changes to support cross-debugging of crashdumps in libkvm were committed to HEAD in r291406.</p> <p>A new thread target for &os; that is suitable for merging @@ -479,7 +479,7 @@ </project> <project cat='kern'> - <title>iMX.6 video output support</title> + <title>iMX.6 Video Output Support</title> <contact> <person> @@ -521,7 +521,7 @@ </project> <project cat='kern'> - <title>Touchscreen support for Raspberry Pi and Beaglebone Black</title> + <title>Touchscreen Support for Raspberry Pi and Beaglebone Black</title> <contact> <person> @@ -614,7 +614,7 @@ vnodes.</p> <p>Vnode cache recycling was reworked to meet free and unused - vnodes targets. Free vnodes are rarely completely free; rather, + vnode targets. Free vnodes are rarely completely free; rather, they are just ones that are cheap to recycle. Usually they are for files which have been stat'd but not read; these usually have inode and namecache data attached to them. The free vnode target @@ -631,18 +631,18 @@ recycling from the free list and normal use maintains this state. Sometimes the free list is below vlowat or even empty, but this state is even better for immediate use, provided the cache is not - full. Otherwise, vnlru_proc() runs to reclaim enough vnodes + full. Otherwise, <tt>vnlru_proc()</tt> runs to reclaim enough vnodes (usually non-free ones) to reach one of these states. The watermarks are currently hard-coded as 4% and 9% of the available space. These, and the default of 25% for wantfreevnodes, are too - large if the memory size is large. E.g., 9% of 75% of MAXVNODES - is more than 566000 vnodes to reclaim whenever vnlru_proc() + large if the memory size is large. For example, 9% of 75% of MAXVNODES + is more than 566000 vnodes to reclaim whenever <tt>vnlru_proc()</tt> becomes active.</p> <p>The <tt>vfs.vlru_alloc_cache_src</tt> sysctl is removed. New code frees namecache sources as the last chance to satisfy the highest watermark, instead of selecting source vnodes randomly. - This provides good enough behaviour to keep vn_fullpath() working + This provides good enough behavior to keep <tt>vn_fullpath()</tt> working in most situations. Filesystem layouts with deep trees, where the removed knob was required, is thus handled automatically.</p> @@ -661,14 +661,14 @@ times at system startup, and then only rarely again. The frees are done only if the vnode zone shrinks, which never happens in practice. For those curious about the avoided work, look at the - vnode_init() and vnode_fini() functions in sys/kern/vfs_subr.c to + <tt>vnode_init()</tt> and <tt>vnode_fini()</tt> functions in sys/kern/vfs_subr.c to see the code that has been removed from the main vnode allocation/free path.</p> </body> </project> <project cat='kern'> - <title>Improvements to QLogic HBA driver</title> + <title>Improvements to the QLogic HBA Driver</title> <contact> <person> @@ -681,8 +681,8 @@ </contact> <body> - <p>The QLogic HBA driver <tt>isp(4)</tt> received a - substantial set of changes. Their primary goal was to make Fibre + <p>The QLogic HBA driver, <tt>isp(4)</tt>, received a + substantial set of changes. The primary goal was to make the Fibre Channel target role work well with CTL, but many other things were also fixed/improved:</p> @@ -727,7 +727,7 @@ </project> <project cat='proj'> - <title>Raspberry Pi: VideoCore userland application packaging</title> + <title>Raspberry Pi: VideoCore Userland Application Packaging</title> <contact> <person> @@ -757,7 +757,7 @@ <tt>misc/raspberrypi-userland</tt> for them. He also created a port for <tt>omxplayer</tt> (a low-level video player that utilizes VideoCore APIs) and is working on a port for Kodi - (ex-XBMC), a more user-firendly media player software with + (formerly XBMC), a more user-firendly media player software with Raspberry Pi support.</p> </body> </project> @@ -786,15 +786,15 @@ It is the product of the merge between the LXDE-Qt and the Razor-qt projects.</p> - <p>The porting effort remains heavily a work in progress: it - needs some components of Plasma 5 (the new major KDE's - workspace).</p> + <p>The porting effort remains very much a work in progress: it + needs some components of Plasma 5, the new major KDE + workspace.</p> <p>Currently, only the 0.10 branch is functional. See our wiki page for a complete list of applications.</p> - <p>We also sent updates for some components of LXDE (required - for the LXQt desktop):</p> + <p>We also sent updates for some components of LXDE, required + for the LXQt desktop:</p> <ul> <li><tt>x11/menu-cache</tt> 1.0.1</li> @@ -851,9 +851,9 @@ new ports, in particular:</p> <ul> - <li>Socket.IO (a library for realtime web applications)</li> + <li>Socket.IO, a library for realtime web applications</li> - <li>Jison (a JavaSript parser generator)</li> + <li>Jison, a JavaSript parser generator</li> </ul> <p>We have improved the USES framework:</p> @@ -865,8 +865,8 @@ <li><tt>node-gyp</tt> is now well-integrated into the USES framework, via the <strong>build</strong> argument.</li> - <li>The <tt>pkg-plist</tt> is now automatically generated, - in order to make the <tt>portlint</tt> utility happy.</li> + <li>The <tt>pkg-plist</tt> is now automatically generated + to make <tt>portlint</tt> happy.</li> </ul> <p>Each port is up-to-date.</p> @@ -923,7 +923,7 @@ <help> <task> - <p>Propose a patch to upstreamto fix Xfdashboard with our + <p>Propose a patch to upstream to fix Xfdashboard with our version of OpenGL (it currently coredumps).</p> </task> </help> @@ -950,7 +950,7 @@ <body> <p>I recently became involved with &os; (as in, the last 2-3 weeks), and found myself quickly involved with Ports development. - What quickly struck me was the difficulty in providing a Python + What struck me immediately was the difficulty in providing a Python package that was depended upon by multiple versions of Python. As it turns out, poudriere can currently only generate one package per port, meaning that a Python version-neutral (compatible with @@ -959,7 +959,7 @@ <p>I discussed the issue with &a.koobs;, who suggested that I look into implementing a "variants protocol" within the - Ports framework and the necessary changes to poudriere in order to + Ports framework and the necessary changes to poudriere to allow a port to generate more than one package.</p> <p>Support for variants is strongly needed in Ports and @@ -994,8 +994,8 @@ in my heels and have implemented a proof-of-concept implementation of variants in the Ports framework, including the necessary modifications to poudriere in order to support it. It was mildly - upsetting to find that poudriere is mostly written in Bourne shell - scripts, but press on I did nonetheless.</p> + upsettling to find that poudriere is mostly written in Bourne shell + scripts, but I pressed on nonetheless.</p> <p>I started with <a href="https://github.com/bapt/ports-wip/compare/variants">the @@ -1007,7 +1007,7 @@ changes.</p> <p>This is a <strong>work in progress</strong>, and I would - love to hear your feedback. I've enjoyed my first few weeks + love to hear your feedback. I have enjoyed my first few weeks working on &os;, and I hope to stay here for quite some time.</p> </body> @@ -1025,7 +1025,7 @@ </project> <project cat='ports'> - <title>New tools to enhance the porting experience</title> + <title>New Tools to Enhance the Porting Experience</title> <contact> <person> @@ -1047,10 +1047,10 @@ <body> <p>When I starting working on ports for &os; in the last couple of weeks, I found that my workflow was not as efficient as - it could be, using just the available tools, so I made a few that + it could be using just the available tools, so I made a few that could be useful to the development community at large. All of - these have been added to the Ports tree, or otherwise will soon be - added, so you can play with them today!</p> + these have been or will soon be added to the Ports tree, + so you can play with them today!</p> <p><tt>pytoport</tt> is a command-line application that generates a skeleton port for a given PyPI package name. It @@ -1073,27 +1073,27 @@ living in git and the larger upstream SVN tree I was using in poudriere. I built a tool called <tt>bandar</tt> that takes advantage of the FUSE version of unionfs to easily overlay my dev - tree on the upstream tree, run linting, poudriere and generate + tree on the upstream tree, run linting, poudriere, and generate archives with ease.</p> - <p>I'm very impressed with how easy it was to build more + <p>I am very impressed with how easy it was to build more tooling for &os;. I hope some of these tools will be of some use to you, and as always, I'd love to hear your feedback!</p> </body> <help> <task> - <p>Improve skog to support searching a tree for a certain + <p>Improve <tt>skog</tt> to support searching a tree for a certain port.</p> </task> <task> - <p>Get the bandar port completed.</p> + <p>Get the <tt>bandar</tt> port completed.</p> </task> <task> - <p>Continue to improve pytoport, adding trove support and better - depedency handling.</p> + <p>Continue to improve <tt>pytoport</tt>, adding <tt>trove</tt> support and better + dependency handling.</p> </task> <task> @@ -1118,14 +1118,14 @@ <body> <p>The Out of Memory (OOM) code is intended to handle the situation where the system needs free memory to make progress, - while no memory can be reused. Most often, the situation is that + but no memory can be reused. Most often, the situation is that to free memory, the system needs more free memory. Consider a case where the system needs to page-out dirty pages, but needs to allocate structures to track the writes. OOM "solves" the problem by killing some selection of user processes. In other words, it trades away system deadlock by suffering a partial loss of user data. The assumption is that it is better to kill a - process and recover data in other processes, than lose + process and recover data in other processes than to lose everything.</p> <p>Free memory in the &os; Virtual Memory (VM) system appears @@ -1133,16 +1133,16 @@ by a process, for example unmapping private anonymous regions, or the last unlink of an otherwise unreferenced file with cached pages. Another source is the pagedaemon, which forcefully frees - pages which carry data, of course, after the data is moved to some + pages which carry data, of course after the data is moved to some other storage, like swap or file blocks. OOM is triggered when the pagedaemon definitely cannot free memory to satisfy the requests.</p> - <p>The old criteria to trigger OOM action was a combination of - low free swap space and a low count of free pages (the later is + <p>The old criteria to trigger the OOM action was a combination of + low free swap space and a low count of free pages (the latter is expressed precisely with the paging targets constants, but this is - not relevant to the discussion). That test is mostly incorrect, - e.g., a low free page state might be caused by a greedy consumer + not relevant to the discussion). That test is mostly incorrect. + For example, a low free page state might be caused by a greedy consumer allocating all pages freed by the page daemon in the current pass, but this does not preclude the page daemon from producing more pages. Also, since page-outs are asynchronous, the previous page @@ -1150,15 +1150,15 @@ they would appear some short time later.</p> <p>More seriously, low swap space does not necessarily indicate - that we are in trouble: lots of pages may not require swap - allocations to freed, e.g., clean pages or pages backed by files. + that we are in trouble: lots of pages might not require swap + allocations to be freed, like clean pages or pages backed by files. The last notion is serious, since swap-less systems were considered as having full swap.</p> <p>Instead of trying to deduce the deadlock from looking at the current VM state, the new OOM handler tracks the history of - page daemon passes. Only if several consequtive passes failed to - meet the paging target is an OOM kill considered neccessary. The + page daemon passes. Only when several consequtive passes failed to + meet the paging target is an OOM kill considered necessary. The count of consequent failed passes was selected empirically, by testing on small (32M) and large (512G) machines. Auto-tuning of the counter is possible, but requires some more architectural @@ -1169,15 +1169,15 @@ pages mapping entries (PTEs) installed into the machine paging structures. For different reasons, machine-dependent VM code (pmap) may remove the pte for a memory-resident page. Under some - circumstances, related to other measures to prevent low memory - deadlock, very large processes which consume all system memory, - could have few or no ptes, and the old OOM selector ignored the + circumstances related to other measures to prevent low memory + deadlock, very large processes which consume all system memory + could have few or no ptes. The old OOM selector ignored the process which caused the deadlock, killing unrelated processes.</p> - <p>A new function vm_pageout_oom_pagecount() was written which + <p>A new function, <tt>vm_pageout_oom_pagecount()</tt>, was written which applies a reasonable heuristic to estimate the number of pages - which would be freed by killing the given process. This + freed by killing the given process. This eliminates the effect of selecting small unrelated processes for OOM kill.</p> @@ -1205,7 +1205,7 @@ </links> <body> - <p>A new driver, <tt>cxgbei</tt>, that enables hardware + <p>A new driver, <tt>cxgbei</tt>, enabling hardware accelerated iSCSI with Chelsio's T5- and T4-based offload-capable cards, has been committed to HEAD. Both Initiator and Target are supported. The wire traffic is standard iSCSI (SCSI over TCP as @@ -1298,7 +1298,7 @@ <help> <task> <p>Test the new release on different versions of &os;, Mac - OS X and Linux. In particular, testing on Mac OS X 10.9 (Mavericks) + OS X, and Linux. In particular, testing on Mac OS X 10.9 (Mavericks) and newer would be greatly appreciated.</p> </task> @@ -1426,7 +1426,7 @@ <body> <p>GitLab is a web-based Git repository manager with many - features that is used by more than 100.000 organizations including + features that is used by more than 100,000 organizations including NASA and Alibaba. It also is a very long-standing entry on the "Wanted Ports" list of the &os; Wiki.</p> @@ -1437,9 +1437,9 @@ committed!</p> <p>While the new version of GitLab 8.3 eases the porting, - there are big changes between the last working port of GitLab + there are big changes since the last working port of GitLab 7.14. Nonetheless, it could be expected to see the next working - port in the first quarter of 2016</p> + port in the first quarter of 2016.</p> </body> <sponsor> @@ -1484,12 +1484,12 @@ was regularly hit by missing IPv6 support when building ports.</p> <p>I did some research into the impact of missing IPv6 support - on the ports tree. The results are that 10.308 of 25.522 ports - are not fetchable when using IPv6. This renders — through - dependencies — a total of 17.715 ports unbuildable from - IPv6-only systems. All you can do than is wait and hope that - distcache.FreeBSD.org caches the distfile. But this will take - some time, which may not be a luxury available when a piece of + on the ports tree. The results are that 10,308 of 25,522 ports + are not fetchable when using IPv6. This renders, through + dependencies, a total of 17,715 ports unbuildable from + IPv6-only systems. All you can do then is wait and hope that + <tt>distcache.FreeBSD.org</tt> caches the distfile. But this will take + some time, which might not be a luxury available when a piece of software in use is hit by a security issue.</p> <p>Based on the research, a promotion campaign for IPv6 was @@ -1528,12 +1528,12 @@ are being worked on in our experimental repository.</p> <p>As in previous quarters, we would like to thank several - people who have contributed with machines, patches and general + people who have contributed with machines, patches, and general help. Tobias Berner, &a.madpilot; (madpilot@), Adriaan de Groot, Ralf Nolden, &a.swills; (swills@), and &a.jpaetzel; (jpaetzel@) have been essential to our work.</p> - <p>The following big updates were landed in the ports tree + <p>The following big updates landed in the ports tree this quarter. In many cases, we have also contributed patches to the upstream projects.</p> @@ -1542,14 +1542,14 @@ <li>Calligra 2.9.1, the latest release of the integrated work applications suite. Calligra had last been updated in the - ports tree in the end of 2013!</li> + ports tree at the end of 2013!</li> <li>PyQt4 4.11.4, QScintilla2 2.9.1 and SIP 4.17.</li> <li>PyQt5 5.5.1. Thanks to the work spearheaded by Guido Falsi and Tobias Berner in the previous quarter, the PyQt5 ports have finally been committed to the ports tree. Not only was this - long-awaited on its own, but it also allows other ports to be + long-awaited on its own, it allows other ports to be updated to their latest versions.</li> <li>QtCreator 3.5.1 and 3.6.0.</li> @@ -1562,7 +1562,7 @@ <p>Work on updating the Qt5 ports to their latest version, as well as porting KDE Frameworks 5 and Plasma 5 to &os;, is well - underway in our experimental area51 repository. At the moment, it + under way in our experimental area51 repository. At the moment, it contains Qt5 5.5.1, KDE Frameworks 5.17.0, Plasma 5.5.1 and KDE Applications 15.12.0.</p> @@ -1580,7 +1580,7 @@ </task> <task> - <p>Land the KDE Frameworks 5 and Plasma 5 ports to the + <p>Land the KDE Frameworks 5 and Plasma 5 ports in the tree.</p> </task> @@ -1626,7 +1626,7 @@ </links> <body> - <p>As of the end of Q4 the ports tree holds a bit more + <p>As of the end of the fourth quarter, the ports tree holds a bit more than 25,000 ports, and the PR count is around 2,000. The activity on the ports tree remains steady, with about 7,000 commits performed by almost 120 active @@ -1638,7 +1638,7 @@ reports were fixed, which makes an increase of about 20% compared to Q3.</p> - <p>In Q4 8 commit bits were taken in for safekeeping, + <p>In Q4, eight commit bits were taken in for safekeeping, following an inactivity period of more than 18 months (lioux, lippe, simon, jhay, max, sumikawa, alexey, sperber). Three new developers were granted a ports commit bit (Kenji @@ -1647,7 +1647,7 @@ <p>Also related to the management of ports commit bits, nox's grants were revoked, since the &os; developers - learnt that Juergen Lock passed away.</p> + learned that Juergen Lock had passed away.</p> <p>On the management side, no changes were made to the portmgr team during Q4.</p> @@ -1656,9 +1656,9 @@ updates or cleanups. Amongst those noticeable changes are the update to GCC 4.9, CMake to 3.4.1, PostgreSQL to 9.4, and ruby-gems to 2.5.0. Some infrastructure changes included the - usage of a WRKSRC different from WRKDIR when NO_WRKSUBDIR - is set, the removal of bsd.cpu.mk from sys.mk, and the - move of QT_NONSTANDARD to bsd.qt.mk.</p> + usage of a <tt>WRKSRC</tt> different from <tt>WRKDIR</tt> when <tt>NO_WRKSUBDIR</tt> + is set, the removal of <tt>bsd.cpu.mk</tt> from <tt>sys.mk</tt>, and the + move of <tt>QT_NONSTANDARD</tt> to <tt>bsd.qt.mk</tt>.</p> </body> <help> @@ -1706,14 +1706,14 @@ </links> <body> - <p>This quarter, the bugmeister team has gained a new member, + <p>The bugmeister team has gained a new member, Mahdi Mokhtari (mokhi64@gmail.com). Mahdi has been contributing to the &os; Project for just over one month. After getting started by creating ports for Chef-Server and MySQL 5.7 (With Bernard Spil's help), an introduction to &a.koobs; led to guidance on appropriate projects, such as Bugzilla development, helping Bugmeister, the Bugzilla Triage team, Developers, and the - Community by making issue tracking better. This is how things are + community by making issue tracking better. This is how things are going so far:</p> <p>Issue Tracking can be either "Defect Tracking for @@ -1727,8 +1727,8 @@ <ul> <li>We have made improvements to the AutoAssigner module - (not yet deployed) that was previousely developed by Marcus to - assign ports' bugs to their maintainers by default, such as: + (not yet deployed) that was previously developed by Marcus to + assign port bugs to their maintainers by default, such as: <ul> <li>Improvements and bugfixes to port detection in @@ -1743,7 +1743,7 @@ <li>We have developed a new module (FBSDAttachment), which automates setting maintainer-approval flag values on attachments under most conditions. This will improve time to resolution, - consistency of triage, and save manual effort on behalf of + consistency of triage, and reduce manual effort by triagers and maintainers.</li> <li>We reported and upstreamed a number of bugs in Bugzilla, working @@ -1777,6 +1777,11 @@ </person> </contact> + <links> + <url href="https://svnweb.freebsd.org/base?view=revision&revision=290548">Commit to Head</url> + <url href="https://svnweb.freebsd.org/base/head/sbin/reboot/reboot.8?r1=290548&r2=290547&pathrev=290548"><tt>reboot(8)</tt>; Manual Page Changes</url> + </links> + <body> <p>One of the long-missing features of &os; was the ability to boot up with a temporary rootfs, configure the kernel to be able @@ -1790,7 +1795,7 @@ init, and running the startup scripts as usual.</p> <p>The project is finished. All the relevant code has been committed - to &os; 11-CURRENT, and is expected to ship with &os; 11.0.</p> + to &os; 11-CURRENT and is expected to ship with &os; 11.0.</p> </body> <sponsor> @@ -1817,10 +1822,10 @@ aims to fill that hole by making it possible to add RCTL rules for read bytes per second (BPS), write BPS, read I/O operations per second (IOPS), and write IOPS. It also adds a new throttling - mechanism, to delay process execution when a limit gets hit.</p> + mechanism to delay process execution when a limit is reached.</p> <p>The project is at the late implementation stage. The major - piece of work left, apart from testing, is to integrate it with + piece of work left apart from testing is to integrate it with ZFS. The project is expected to ship with &os; 11.0.</p> </body> @@ -1847,7 +1852,7 @@ <body> <p>The &os; Release Engineering Team is responsible for setting and publishing release schedules for official project releases - of &os;, announcing code freezes and maintaining the + of &os;, announcing code freezes, and maintaining the respective branches, among other things.</p> <p>During the last quarter of 2015, the Release Engineering team @@ -1863,7 +1868,7 @@ <p>Toward the end of the year, much of the primary focus was centered around the upcoming &os; 10.3 release cycle, - which will begin during January 2016.</p> + which will begin in January 2016.</p> <p>As always, help testing development snapshot builds is crucial to producing quality releases, and we encourage @@ -1895,17 +1900,17 @@ </links> <body> - <p>The goal of this project is to reimplement the exisitng + <p>The goal of this project is to reimplement the existing MMC/SD stack using the CAM framework. This will permit utilizing the well-tested CAM locking model and debug features. - Additionally, it will be possible to process interrupts generated + It will also be possible to process interrupts generated by the inserted card, which is a prerequisite for implementing the SDIO interface.</p> <p>The first version of the code was uploaded to Phabricator for review. The new stack is able to attach to the SD - card and bring it to an operational state, so it is possible to - read and write to/from the card.</p> + card and bring it to an operational state so it is possible to + read and write to the card.</p> <p>The only supported SD controller driver is <tt>ti_sdhci</tt>, which is used on the BeagleBone Black. @@ -1915,14 +1920,14 @@ <help> <task> - <p>Rework bus/target/LUN enumeration and the locking model - — I don't really understand the CAM locking and am likely to + <p>Rework bus/target/LUN enumeration and the locking model. + I do not really understand the CAM locking and am likely to do it incorrectly.</p> </task> <task> - <p>Modify the SDHCI driver on at least one x86 platform - — this will make development and collaboration easier.</p> + <p>Modify the SDHCI driver on at least one x86 platform. + This will make development and collaboration easier.</p> </task> <task> @@ -1932,7 +1937,7 @@ </project> <project cat="proj"> - <title>The Graphics stack on &os;</title> + <title>The Graphics Stack on &os;</title> <contact> <person> @@ -2005,7 +2010,7 @@ passwords kept in memory by a browser when a kernel panic occurred. An entity that can read data from a dump device or a crash directory can also extract this information from a core - dump. In order to prevent this situation, the core dump should be + dump. To prevent this situation, the core dump should be encrypted before it is stored on the dump device.</p> <p>This project allows a kernel to encrypt a core dump during @@ -2072,14 +2077,14 @@ involved with the &os; Project. This experimental pilot project has the task of setting up procedures for enhanced Issue (Problem Report) management that include better - classification/prioritization, eventually leading to faster - resolution of the issues.</p> + classification and prioritization, eventually leading to faster + resolution of issues.</p> <p>We are now happy to report on the progress of this experimental team:</p> <ul> - <li>We have set up the #FreeBSD-bugs IRC channel on + <li>The #FreeBSD-bugs IRC channel has been set up on Freenode and we are successfully using it to exchange information about triage processes, ask for help, propose changes and discuss related topics.</li> @@ -2098,9 +2103,9 @@ <li>This experiment is benefiting from the introduction of newcomers to issue tracking. It naturally resulted in a entire - review of the tracking proccess from its very elementary aspects. + review of the tracking process from its very elementary aspects. This "fresh eyes" participation spotted minor details - along the proccess, giving the opportunity to scrutinize actual + along the process, giving the opportunity to scrutinize actual procedures on a number of smaller points, followed by proposals on how to improve the overall Issue Tracking and Management. The new ideas include both organizational and technical ideas and @@ -2108,10 +2113,11 @@ classification, the triage workflow, and Bugzilla technical improvements among others.</li> - <li>An important goal is producing documentation not only - aimed at people directly engaged on issue triage tasks, but also - documentation aimed at general users, about best practices for - using Bugzilla and the issue management workflow. Another + <li>An important goal is producing documentation about best + practices for using Bugzilla and issue management workflow. + This documentation should be aimed not only at people directly + engaged in issue triage tasks, but also at general users. + Another relevant point is that feedback from triage team can be used to improve Bugzilla in terms of adjusting existing features to best fit &os;'s needs, and development of new features (please see @@ -2126,7 +2132,7 @@ report.</li> </ul> <p>Since the Issue Triage Team is very young, we expect more - information be available and more actions be reported upon in the + information be available and more actions be reported in the next Status report.</p> </body> @@ -2152,7 +2158,7 @@ </project> <project cat='misc'> - <title>relaunchd</title> + <title><tt>relaunchd</tt></title> <contact> <person> @@ -2201,7 +2207,7 @@ <task> <p>Add support for monitoring files and directories for - changes, and launching jobs when changes are detected.</p> + changes and launching jobs when changes are detected.</p> </task> <task> @@ -2210,14 +2216,14 @@ </task> <task> - <p>Improve the documentation and providing more examples of - how to use it.</p> + <p>Improve the documentation and provide more examples of + usage.</p> </task> </help> </project> <project cat='kern'> - <title>&os; Integration Services (BIS) </title> + <title>&os; Integration Services (BIS)</title> <contact> <person> @@ -2243,21 +2249,22 @@ </links> <body> - <p>When &os; virtual machines (VMs) run on Hyper-V, in order + <p>When &os; virtual machines (VMs) run on Hyper-V, using + Hyper-V synthetic devices is recommended to get the best network and storage performance and make full use - of all the benefits that Hyper-V provides, it is recommended to - use Hyper-V synthetic devices. The collection of drivers that are + of all the benefits that Hyper-V provides. + The collection of drivers that are required to run Hyper-V synthetic devices in &os; are known as &os; Integration Services (BIS). Some of the BIS drivers (like network and storage drivers) have existed in &os; 9.x and 10.x for years, but there are still some performance and stability issues - and bugs. Additionally, compared with Windows and Linux VMs, the - current BIS lacks some important features, such as the virtual + and bugs. Compared with Windows and Linux VMs, the + current BIS lacks some important features, such as virtual Receive Side Scaling (vRSS) support in the Hyper-V network driver - and the support for UEFI VM (boot from UEFI), among others.</p> + and support for UEFI VM (boot from UEFI), among others.</p> <p>We are now working more on the issues and performance - tuning to make &os; VM run better on Hyper-V and the Hyper-V based + tuning to make &os; VMs run better on Hyper-V and the Hyper-V based cloud platform Azure.</p> <p>Our work during 2015Q4 is documented below:</p> @@ -2301,7 +2308,7 @@ <li>Added ioctl support for SIOCGIFMEDIA for the Hyper-V network driver, fixing PR 187006 ([Hyper-V] dynamic - address (DHCP) obtaining doesn't work on HYPER-V OS + address (DHCP) obtaining does not work on HYPER-V OS 2012 R2).</li> <li>Sent out patches to add an interrupt counter for @@ -2322,18 +2329,18 @@ </ul> </li> - <li>We plan to add support for UEFI VMs (a.k.a., Hyper-V + <li>We plan to add support for UEFI VMs (Hyper-V Generation-2 VMs). Currently some issues and to-do items were - identified: e.g., we cannot use the i8254 PIT to calibrate the + identified. For example, we cannot use the i8254 PIT to calibrate the TSC because the i8254 PIT does not exist in a UEFI VM, and we need to add support for the Hyper-V synthetic keyboard/mouse/framebuffer device.</li> <li>We are working on a disk detection issue: when a &os; VM runs on a Windows Server 2016 Technical Preview host, the VM - will detect 16 disks whereas only 1 disk is configured for the - VM. Due to this issue, VMs running on these hosts can fail to - boot. A workaround patch was made and we are trying to make a + will detect 16 disks when only one disk is configured for the + VM. VMs running on these hosts can fail to + boot. A workaround patch was created and we are trying to make a formal fix.</li> <li>We are tidying up some internal BIS test cases and plan @@ -2347,7 +2354,7 @@ </project> <project cat='proj'> - <title>Mellanox iSCSI Extensions For RDMA (iSER) Support</title> + <title>Mellanox iSCSI Extensions for RDMA (iSER) Support</title> <contact> <person> @@ -2404,7 +2411,7 @@ </project> <project cat='arch'> - <title>Improvements for ARMv6/v7 support</title> + <title>Improvements for ARMv6/v7 Support</title> <contact> <person> @@ -2677,15 +2684,15 @@ scalability and the ability to add advanced features to the routing stack.</p> - <p>Currently, the packet output path suffers from excessive - locking, acquiring and releasing 4 distinct contested locks is - required in order to convert a packet to a frame suitable to put + <p>The current packet output path suffers from excessive + locking. Acquiring and releasing four distinct contested locks is + required to convert a packet to a frame suitable to put on the wire. The first project goal is to reduce the number of locks needed to just two <tt>rmlock(9)</tt>s for the output path, which permits close-to-linear scaling.</p> <p>Since September, one of the locks (used to protect - link-level entries) is completely eliminated from the packet data + link-level entries) has been completely eliminated from the packet data path. A new routing API was introduced, featuring better scalability and hiding routing internals. Most of the consumers of the old routing API were converted to use the new API.</p> @@ -2714,13 +2721,13 @@ <body> <p>&a.bdrewery; (bdrewery@) has been working to improve the - build framework as well as buildworld build times. The build - system has largely been untouched by large-scale changes for many + build framework as well as <tt>buildworld</tt> build times. The build + system has been largely untouched by large-scale changes for many years. Most of the effort has been on improving the recent <tt>META_MODE</tt> merge that was presented at BSDCan 2014. This is a new build system that is not currently enabled by default but brings many benefits. Beyond that, some highlights of the work - changing buildworld are:</p> + changing <tt>buildworld</tt> are:</p> <ul> <li><tt>WITH_FAST_DEPEND</tt>, which avoids calling @@ -2729,15 +2736,15 @@ scheme was pre-processing all source files twice. The new version saves 16-35% in build times.</li> - <li><tt>WITH_CCACHE_BUILD</tt> adds built-in ccache support, + <li><tt>WITH_CCACHE_BUILD</tt> adds built-in <tt>ccache</tt> support, avoiding many of the historical pitfalls of changing <tt>CC</tt> - in <tt>make.conf</tt> to use ccache.</li> + in <tt>make.conf</tt> to use <tt>ccache</tt>.</li> <li>Many improvements for parallelization of the build.</li> <li><tt>LIBADD</tt> improvements to ensure proper usage of this tool to replace duplicate <tt>LDADD</tt> and <tt>DPADD</tt> - statements. Further work is underway to reduce overlinking.</li> + statements. Further work is under way to reduce overlinking.</li> <li>A lot of cleanup of improper framework usage.</li> @@ -2760,7 +2767,7 @@ </project> <project cat='bin'> - <title>ELF Tool Chain tools</title> + <title>ELF Tool Chain Tools</title> <contact> <person> *** DIFF OUTPUT TRUNCATED AT 1000 LINES ***
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201601312151.u0VLpeKR013447>