Date: Sun, 31 Jan 2016 22:49:41 +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: r48133 - head/en_US.ISO8859-1/htdocs/news/status Message-ID: <201601312249.u0VMnf0B028256@repo.freebsd.org>
next in thread | raw e-mail | index | archive | help
Author: wblock Date: Sun Jan 31 22:49:41 2016 New Revision: 48133 URL: https://svnweb.freebsd.org/changeset/doc/48133 Log: Whitespace-only fixes, translators please ignore. 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 21:51:40 2016 (r48132) +++ head/en_US.ISO8859-1/htdocs/news/status/report-2015-10-2015-12.xml Sun Jan 31 22:49:41 2016 (r48133) @@ -16,9 +16,9 @@ <title>Introduction</title> <p><strong>This is a draft of the October–December 2015 - status report. Please check back after it is finalized, and - an announcement email is sent to the &os;-Announce mailing - list.</strong></p> + status report. Please check back after it is finalized, and + an announcement email is sent to the &os;-Announce mailing + list.</strong></p> <?ignore <p>This report covers &os;-related projects between October and @@ -26,13 +26,13 @@ 2015.</p> <p>The fourth quarter of 2015 was another productive quarter for - the &os; project and community. [...]</p> + the &os; project and community. [...]</p> <p>Thanks to all the reporters for the excellent work!</p> <p>The deadline for submissions covering the period from January to March 2016 is April 7, 2016.</p> - ?> + ?> </section> <category> @@ -84,7 +84,8 @@ </category> <project cat='ports'> - <title>Linux Kernel as a Library Added to the Ports Collection</title> + <title>Linux Kernel as a Library Added to the Ports + Collection</title> <contact> <person> @@ -102,10 +103,10 @@ <body> <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 filesystem drivers - to implement a FUSE backend.</p> + "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 filesystem + drivers to implement a FUSE backend.</p> <p>fusefs-lkl's <tt>lklfuse</tt> binary is such a FUSE filesystem. It can mount <tt>ext4/3/2</tt>, <tt>XFS</tt>, and @@ -119,7 +120,8 @@ </project> <project cat='doc'> - <title><tt>style(9)</tt> Enhanced to Allow C99 <tt>bool</tt></title> + <title><tt>style(9)</tt> Enhanced to Allow C99 + <tt>bool</tt></title> <contact> <person> @@ -146,8 +148,8 @@ <body> <p>Use of <tt>bool</tt> is now allowed. It was allowed - previously, as well, but now it is <em>really</em> allowed. Party - like it's 1999!</p> + previously, as well, but now it is <em>really</em> allowed. + Party like it's 1999!</p> </body> <sponsor> @@ -156,7 +158,8 @@ <help> <task> - <p>Specify <tt>style(9)</tt>'s opinion on <tt>iso646.h.</tt></p> + <p>Specify <tt>style(9)</tt>'s opinion on + <tt>iso646.h.</tt></p> </task> <task> @@ -201,15 +204,16 @@ </links> <body> - <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 <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> + <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 <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> <sponsor> @@ -236,17 +240,16 @@ </links> <body> - <p> I/OAT DMA engines are bulk memory operation offload - engines built into some Intel Server/Storage platform - CPUs.</p> - - <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 + <p>I/OAT DMA engines are bulk memory operation offload engines + built into some Intel Server/Storage platform CPUs.</p> + + <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 - operation have been added to the API. The driver can recover from - various programming errors by resetting the hardware.</p> + operation have been added to the API. The driver can recover + from various programming errors by resetting the hardware.</p> </body> <sponsor> @@ -255,13 +258,15 @@ <help> <task> - <p>XOR and other advanced ("RAID") operation support.</p> + <p>XOR and other advanced ("RAID") operation + support.</p> </task> </help> </project> <project cat='kern'> - <title><tt>ntb_hw(4)</tt>/<tt>if_ntb(4)</tt> 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> @@ -279,16 +284,17 @@ </links> <body> - <p><tt>ntb_hw(4)</tt> is now up-to-date with the Linux NTB driver as - of the work-in-progress 4.4 kernel (and actually, contains some - fixes that haven't landed in the mainline Linux tree yet but will - land in 4.5). Only Back-to-back ("B2B") configurations - are supported at this time. Going forward, newer hardware may - only support the B2B configuration.</p> - - <p><tt>if_ntb(4)</tt> is mostly up-to-date with the Linux NTB netdevice - driver. Notably absent is support for changing the MTU at - runtime.</p> + <p><tt>ntb_hw(4)</tt> is now up-to-date with the Linux NTB + driver as of the work-in-progress 4.4 kernel (and actually, + contains some fixes that haven't landed in the mainline Linux + tree yet but will land in 4.5). Only Back-to-back + ("B2B") configurations are supported at this time. + Going forward, newer hardware may only support the B2B + configuration.</p> + + <p><tt>if_ntb(4)</tt> is mostly up-to-date with the Linux NTB + netdevice driver. Notably absent is support for changing the + MTU at runtime.</p> </body> <sponsor> @@ -298,8 +304,8 @@ <help> <task> <p>Improving <tt>if_ntb(4)</tt> to avoid using the entire Base - Address Register (BAR) when very large BAR sizes are configured - (e.g., 512 GB).</p> + Address Register (BAR) when very large BAR sizes are + configured (e.g., 512 GB).</p> </task> <task> @@ -337,13 +343,12 @@ </links> <body> - <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 - 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 - (<tt>if_dwc</tt>).</p> + <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 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 (<tt>if_dwc</tt>).</p> </body> </project> @@ -369,16 +374,16 @@ <p>The Mellanox &os; team is proud to announce support for the ConnectX-4 series of network cards in &os; 11-current and &os; 10-stable. These devices deliver top performance, with up to - 100GBit/s of raw transfer capacity, and support both Ethernet and - Infiniband. Currently, the Ethernet driver is ready for use and - the Infiniband support for ConnectX-4 is making good progress. We - hope that it will be complete before &os; 11.0 is released. For - more technical information, refer to the <tt>mlx5en(4)</tt> manual - page in 11-current. The new driver for ConnectX-4 cards is called - <tt>mlx5</tt> and is put under <tt>/sys/dev</tt> and not under - <tt>/sys/ofed</tt> as was done for the previous - <tt>mlx4</tt> driver. The <tt>mlx5en(4)</tt> kernel module is - compiled by default in GENERIC kernels.</p> + 100GBit/s of raw transfer capacity, and support both Ethernet + and Infiniband. Currently, the Ethernet driver is ready for + use and the Infiniband support for ConnectX-4 is making good + progress. We hope that it will be complete before &os; 11.0 + is released. For more technical information, refer to the + <tt>mlx5en(4)</tt> manual page in 11-current. The new driver + for ConnectX-4 cards is called <tt>mlx5</tt> and is put under + <tt>/sys/dev</tt> and not under <tt>/sys/ofed</tt> as was done + for the previous <tt>mlx4</tt> driver. The <tt>mlx5en(4)</tt> + kernel module is compiled by default in GENERIC kernels.</p> </body> <sponsor> @@ -406,16 +411,16 @@ <body> <p><u>FreeBSD Mastery: Specialty Filesystems</u> is now in - copyediting. The ebook should be available by the end of January - at all major vendors, and the print in February.</p> + copyediting. The ebook should be available by the end of + January at all major vendors, and the print in February.</p> <p>The book covers everything from removable media, to FUSE, 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 will get the final ebook when - it comes out as well. (This offer evaporates when the final - version comes out.)</p> + 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> </project> @@ -437,20 +442,21 @@ </links> <body> - <p>The KGDB option is now on by default in the <tt>devel/gdb</tt> - port.</p> + <p>The KGDB option is now on by default in the + <tt>devel/gdb</tt> port.</p> - <p>Changes to support cross-debugging of crashdumps in - libkvm were committed to HEAD in r291406.</p> + <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 - upstream has been written and lightly tested. However, it is not - yet available as an option in the port. This thread target uses - <tt>ptrace(2)</tt> directly rather than <tt>libthread_db</tt> and - as such supports threads on all ABIs (such as &os;/i386 binaries - on &os;/amd64 and possibly Linux binaries, though that is not yet - tested). It also requires less-invasive changes in the MD targets - in GDB compared to the <tt>libthread_db</tt>-based target.</p> + upstream has been written and lightly tested. However, it is + not yet available as an option in the port. This thread + target uses <tt>ptrace(2)</tt> directly rather than + <tt>libthread_db</tt> and as such supports threads on all ABIs + (such as &os;/i386 binaries on &os;/amd64 and possibly Linux + binaries, though that is not yet tested). It also requires + less-invasive changes in the MD targets in GDB compared to the + <tt>libthread_db</tt>-based target.</p> </body> <help> @@ -469,7 +475,8 @@ <task> <p>Add support for more platforms (arm, mips, aarch64) to - upstream <tt>gdb</tt> for both userland and <tt>kgdb</tt>.</p> + upstream <tt>gdb</tt> for both userland and + <tt>kgdb</tt>.</p> </task> <task> @@ -496,9 +503,9 @@ </links> <body> - <p>iMX.6 is a family of SoC used in multiple hobbyist ARM - boards such as the Hummingboard, RIoTboard, and Cubox. Most of - these products have HDMI output, but until recently, &os; did not + <p>iMX.6 is a family of SoC used in multiple hobbyist ARM boards + such as the Hummingboard, RIoTboard, and Cubox. Most of these + products have HDMI output, but until recently, &os; did not benefit from it. As of r292574, there is basic video output support so you can use the console on iMX6-based boards and probably run Xorg (not yet tested).</p> @@ -521,7 +528,8 @@ </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> @@ -541,17 +549,17 @@ <body> <p>There are two working proof-of-concept drivers for the - AM335x touchscreen and for the official Raspberry Pi's touchscreen - LCD.</p> - + AM335x touchscreen and for the official Raspberry Pi's + touchscreen LCD.</p> + <p>Proper touchscreen support would consist of a userland event reading API, a kernel event reporting API, and kernel hardware - drivers for specific devices. There is an ongoing effort to port - the Linux evdev API to &os; so applications that use libraries like - libinput or tslib could be used without any major changes. Since - it is not yet complete, I created a naive evdev-like API for both - kernel and tslib and was able to run a demo on a Beaglebone Black - with 4DCAPE-43T.</p> + drivers for specific devices. There is an ongoing effort to + port the Linux evdev API to &os; so applications that use + libraries like libinput or tslib could be used without any + major changes. Since it is not yet complete, I created a + naive evdev-like API for both kernel and tslib and was able to + run a demo on a Beaglebone Black with 4DCAPE-43T.</p> <p>Once evdev makes it into the tree, both hardware drivers can be modified to include "report events" @@ -610,59 +618,61 @@ <body> <p>This completed project includes changes to better manage - the vnode freelist and to streamline the allocation and freeing of - vnodes.</p> + the vnode freelist and to streamline the allocation and + freeing of vnodes.</p> <p>Vnode cache recycling was reworked to meet free and unused - 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 - is the preferred minimum size of a sub-cache consisting mostly of - such files. The system balances the size of this sub-cache with - its complement to try to prevent either from thrashing while the - other is relatively inactive. The targets express a preference - for the best balance.</p> + 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 is the preferred minimum size of a sub-cache + consisting mostly of such files. The system balances the size + of this sub-cache with its complement to try to prevent either + from thrashing while the other is relatively inactive. The + targets express a preference for the best balance.</p> <p>"Above" this target there are 2 further targets (watermarks) related to the recyling of free vnodes. In the - best-operating case, the cache is exactly full, the free list has - size between vlowat and vhiwat above the free target, and - 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, <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. 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 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> + best-operating case, the cache is exactly full, the free list + has size between vlowat and vhiwat above the free target, and + 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, <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. + 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 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> <p>As the kernel allocates and frees vnodes, it fully - initializes them on every allocation and fully releases them on - every free. These are not trivial costs: it starts by zeroing a - large structure, then initializes a mutex, a lock manager lock, an - rw lock, four lists, and six pointers. Looking at - <tt>vfs.vnodes_created</tt>, these operations are being done - millions of times an hour on a busy machine.</p> + initializes them on every allocation and fully releases them + on every free. These are not trivial costs: it starts by + zeroing a large structure, then initializes a mutex, a lock + manager lock, an rw lock, four lists, and six pointers. + Looking at <tt>vfs.vnodes_created</tt>, these operations are + being done millions of times an hour on a busy machine.</p> <p>As a performance optimization, this code update uses the uma_init and uma_fini routines to do these initializations and - cleanups only as the vnodes enter and leave the vnode zone. With - this change, the initializations are done <tt>kern.maxvnodes</tt> - 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 - <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 + cleanups only as the vnodes enter and leave the vnode zone. + With this change, the initializations are done + <tt>kern.maxvnodes</tt> 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 <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> @@ -682,9 +692,9 @@ <body> <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> + 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> <ul> <li>Added support for modern 16Gbps 26xx FC cards.</li> @@ -692,23 +702,26 @@ <li>The firmware in <tt>ispfw(4)</tt> were updated to the latest versions.</li> - <li>Target role support was fixed and tested for all FC cards from - ancient 1Gbps 22xx to modern 16Gbps 26xx.</li> + <li>Target role support was fixed and tested for all FC cards + from ancient 1Gbps 22xx to modern 16Gbps 26xx.</li> - <li>Port database handling was unified for target and initiator - roles, allowing HBA port to play both roles at the same time.</li> + <li>Port database handling was unified for target and + initiator roles, allowing HBA port to play both roles at the + same time.</li> <li>The maximal number of ports was increased from 256 to 1024.</li> - <li>Multi-ID (NPIV) functionality was fixed/implemented, allowing - 24xx and above cards to provide up to 255 virtual FC ports per - physical port.</li> + <li>Multi-ID (NPIV) functionality was fixed/implemented, + allowing 24xx and above cards to provide up to 255 virtual + FC ports per physical port.</li> - <li>Added support for 8-byte LUNs for 24xx and above cards.</li> + <li>Added support for 8-byte LUNs for 24xx and above + cards.</li> </ul> - <p>The code is committed to &os; head and stable/10 branches.</p> + <p>The code is committed to &os; head and stable/10 + branches.</p> </body> <sponsor> @@ -727,7 +740,8 @@ </project> <project cat='proj'> - <title>Raspberry Pi: VideoCore Userland Application Packaging</title> + <title>Raspberry Pi: VideoCore Userland Application + Packaging</title> <contact> <person> @@ -750,15 +764,15 @@ <body> <p>The Raspberry Pi SoC consists of two parts: ARM and GPU (VideoCore). Many interesting features like OpenGL, video - playback, and HDMI controls are implemented on the VideoCore side - and can be accessed from the OS through libraries provided by - Broadcom (userland repo). These libraries were ported to &os; - some time ago, so Mikaël created the port - <tt>misc/raspberrypi-userland</tt> for them. He also created a - port for <tt>omxplayer</tt> (a low-level video player that + playback, and HDMI controls are implemented on the VideoCore + side and can be accessed from the OS through libraries + provided by Broadcom (userland repo). These libraries were + ported to &os; some time ago, so Mikaël created the port + <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 - (formerly XBMC), a more user-firendly media player software with - Raspberry Pi support.</p> + (formerly XBMC), a more user-firendly media player software + with Raspberry Pi support.</p> </body> </project> @@ -782,16 +796,16 @@ <body> <p><a href="http://lxqt.org/">LXQt</a>; is the Qt port of and - the upcoming version of LXDE, the Lightweight Desktop Environment. - It is the product of the merge between the LXDE-Qt and the - Razor-qt projects.</p> + the upcoming version of LXDE, the Lightweight Desktop + Environment. It is the product of the merge between the + LXDE-Qt and the Razor-qt projects.</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>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> @@ -802,9 +816,8 @@ <li><tt>x11/lxmenu-data</tt> 0.1.4</li> </ul> - <p>Binary packages are available (only for test purposes) - which are regularly tested with the KDE development - repository.</p> + <p>Binary packages are available (only for test purposes) which + are regularly tested with the KDE development repository.</p> </body> <help> @@ -838,14 +851,15 @@ <body> <p>Node.js is a platform built on Chrome's JavaScript runtime - for easily building fast, scalable network applications. It uses - an event-driven, non-blocking I/O model that makes it lightweight - and efficient — perfect for data-intensive real-time applications - that run across distributed devices.</p> + for easily building fast, scalable network applications. It + uses an event-driven, non-blocking I/O model that makes it + lightweight and efficient — perfect for data-intensive + real-time applications that run across distributed + devices.</p> <p>The goal of this project is to make it easy to install the - modules available in the <a href="http://npmjs.org/">npm package - registry</a>.</p> + modules available in the + <a href="http://npmjs.org/">npm package registry</a>.</p> <p>Currently, the repository contains slightly fewer than 300 new ports, in particular:</p> @@ -878,7 +892,8 @@ </task> <task> - <p>Bring in grunt.js (and modules), the JavaScript task runner.</p> + <p>Bring in grunt.js (and modules), the JavaScript task + runner.</p> </task> </help> </project> @@ -949,17 +964,18 @@ <body> <p>I recently became involved with &os; (as in, the last 2-3 - weeks), and found myself quickly involved with Ports development. - 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 - 2.x and 3.x) port cannot simultaneously be packaged for each - variant at the same time.</p> + weeks), and found myself quickly involved with Ports + development. 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 2.x and 3.x) port cannot + simultaneously be packaged for each variant at the same + time.</p> <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 to + look into implementing a "variants protocol" within + the 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 @@ -967,16 +983,16 @@ <ul> <li>It would allow Python and other languages to provide - packages for dependencies for multiple language versions from the - same port.</li> + packages for dependencies for multiple language versions + from the same port.</li> <li>It alleviates the need for so-called "slave - ports", as a single port could now have multiple generated - packages from a single port.</li> + ports", as a single port could now have multiple + generated packages from a single port.</li> <li>It would have a very small impact on the greater Ports - ecosystem: adding only two new variables, <tt>VARIANT</tt> and - <tt>VARIANTS</tt>.</li> + ecosystem: adding only two new variables, <tt>VARIANT</tt> + and <tt>VARIANTS</tt>.</li> <li>It would provide a more consistent approach between different packaging teams for handling variations.</li> @@ -991,24 +1007,25 @@ consistently generated by poudriere without issue.</p> <p>Fortunately, this is not a wishful thinking piece. I dug - 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 - 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 - prototype made by &a.bapt;</a> as a base, and built from there. - The poudriere PoC aims to limit changes as much as possible to - merely adding support for the new variants flags, while also at - the request of &a.koobs; making the logging output more - package-centric (as opposed to port-centric) as a result of these - changes.</p> + 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 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 prototype made by &a.bapt;</a> + as a base, and built from there. The poudriere PoC aims to + limit changes as much as possible to merely adding support for + the new variants flags, while also at the request of &a.koobs; + making the logging output more package-centric (as opposed to + port-centric) as a result of these changes.</p> <p>This is a <strong>work in progress</strong>, and I would 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> + working on &os;, and I hope to stay here for quite some + time.</p> </body> <help> @@ -1018,8 +1035,8 @@ </task> <task> - <p>Hopefully the code will be of sufficient quality to be considered - for formal review in the coming months.</p> + <p>Hopefully the code will be of sufficient quality to be + considered for formal review in the coming months.</p> </task> </help> </project> @@ -1045,46 +1062,46 @@ </links> <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 + <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 could be useful to the development community at large. All of - these have been or will soon be added to the Ports tree, - 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 attempts to generate the correct dependencies, makes a good - attempt at guessing the license using <tt>spdx-lookup</tt>, and - generates a <tt>pkg-descr</tt>. This made generating the fifteen - or so ports I was working on a complete breeze.</p> + attempt at guessing the license using <tt>spdx-lookup</tt>, + and generates a <tt>pkg-descr</tt>. This made generating the + fifteen or so ports I was working on a complete breeze.</p> <p>While doing this, however, I noticed that some ports were - bringing in dependencies that I did not expect, and I needed some - way to visualise this. <tt>skog</tt> builds a dependency tree - from the depends lists output by the Ports framework, and displays - it on the command line (with extra shiny output if you are using - UTF-8). No more pesky example and documentation dependencies - being dragged in when you <em>clearly</em> toggled that - <tt>OPTION</tt> as far off as it would go.</p> - - <p>While doing all of this, I found it cumbersome to be - copying ports back and forth between my small development tree - living in git and the larger upstream SVN tree I was using in + bringing in dependencies that I did not expect, and I needed + some way to visualise this. <tt>skog</tt> builds a dependency + tree from the depends lists output by the Ports framework, and + displays it on the command line (with extra shiny output if + you are using UTF-8). No more pesky example and documentation + dependencies being dragged in when you <em>clearly</em> + toggled that <tt>OPTION</tt> as far off as it would go.</p> + + <p>While doing all of this, I found it cumbersome to be copying + ports back and forth between my small development tree 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 - archives with ease.</p> + advantage of the FUSE version of unionfs to easily overlay my + dev tree on the upstream tree, run linting, poudriere, and + generate archives with ease.</p> <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> + 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 <tt>skog</tt> to support searching a tree for a certain - port.</p> + <p>Improve <tt>skog</tt> to support searching a tree for a + certain port.</p> </task> <task> @@ -1092,8 +1109,8 @@ </task> <task> - <p>Continue to improve <tt>pytoport</tt>, adding <tt>trove</tt> support and better - dependency handling.</p> + <p>Continue to improve <tt>pytoport</tt>, adding + <tt>trove</tt> support and better dependency handling.</p> </task> <task> @@ -1118,68 +1135,70 @@ <body> <p>The Out of Memory (OOM) code is intended to handle the situation where the system needs free memory to make progress, - 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 to lose - everything.</p> + 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 to lose everything.</p> <p>Free memory in the &os; Virtual Memory (VM) system appears - from two sources. One is the voluntary reclamation of pages used - 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 - 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 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. - 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 - daemon pass might not immmediately produce any free pages, but - they would appear some short time later.</p> + from two sources. One is the voluntary reclamation of pages + used 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 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 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. 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 daemon + pass might not immmediately produce any free pages, but 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 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 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 - changes to the I/O subsystem.</p> + 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 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 changes to the I/O + subsystem.</p> - <p>Another issue was identified with the algorithm which - selects a victim process for OOM kill. It compared the counts of + <p>Another issue was identified with the algorithm which selects + a victim process for OOM kill. It compared the counts of 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. The old OOM selector ignored the - process which caused the deadlock, killing unrelated - processes.</p> - - <p>A new function, <tt>vm_pageout_oom_pagecount()</tt>, was written which - applies a reasonable heuristic to estimate the number of pages - freed by killing the given process. This - eliminates the effect of selecting small unrelated processes for - OOM kill.</p> + (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. The old OOM selector + ignored the process which caused the deadlock, killing + unrelated processes.</p> + + <p>A new function, <tt>vm_pageout_oom_pagecount()</tt>, was + written which applies a reasonable heuristic to estimate the + number of pages freed by killing the given process. This + eliminates the effect of selecting small unrelated processes + for OOM kill.</p> <p>The rewrite was committed to HEAD in r290917 and r290920.</p> </body> @@ -1205,15 +1224,16 @@ </links> <body> - <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 - per RFC 3720, etc.) so an Initiator/Target using this driver will - interoperate with all other standards-compliant + <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 per RFC 3720, etc.) so an Initiator/Target using this + driver will interoperate with all other standards-compliant implementations.</p> - <p>Hardware assistance provided by the T5 and T4 ASICs includes:</p> + <p>Hardware assistance provided by the T5 and T4 ASICs + includes:</p> <ul> <li>Complete TCP processing.</li> @@ -1240,8 +1260,9 @@ <task> <p>The driver is in advanced stage QA and will see some - bugfixes and performance enhancements in the very near future. - MFC is possible as soon as the QA cycle completes.</p> + bugfixes and performance enhancements in the very near + future. MFC is possible as soon as the QA cycle + completes.</p> </task> </help> </project> @@ -1280,16 +1301,16 @@ <body> <p>OpenBSM is a BSD-licensed implementation of Sun's Basic - Security Module (BSM) API and file format. It is the user-space - side of the CAPP Audit implementations in &os; and Mac OS X. - Additionally, the audit trail processing tools are expected to - work on Linux.</p> + Security Module (BSM) API and file format. It is the + user-space side of the CAPP Audit implementations in &os; and + Mac OS X. Additionally, the audit trail processing tools are + expected to work on Linux.</p> <p>Progress has been slow but steady this quarter, culminating in OpenBSM 1.2 alpha 4, the first release in three years. It features various bug fixes and documentation improvements; the - complete list of changes is documented in the <a - href="https://github.com/openbsm/openbsm/blob/master/NEWS">NEWS</a>; + complete list of changes is documented in the + <a href="https://github.com/openbsm/openbsm/blob/master/NEWS">NEWS</a>; file on GitHub. The release was imported into &os; HEAD and merged to &os; 10-STABLE. As such it will be part of &os; 10.3-RELEASE.</p> @@ -1297,9 +1318,9 @@ <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) - and newer would be greatly appreciated.</p> + <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) and newer would be greatly appreciated.</p> </task> <task> @@ -1354,12 +1375,12 @@ <body> *** DIFF OUTPUT TRUNCATED AT 1000 LINES ***
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201601312249.u0VMnf0B028256>