Date: Thu, 17 Oct 2013 15:15:59 +0000 (UTC) From: Gabor Pali <pgj@FreeBSD.org> To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r42983 - head/en_US.ISO8859-1/htdocs/news/status Message-ID: <201310171515.r9HFFxcM056558@svn.freebsd.org>
next in thread | raw e-mail | index | archive | help
Author: pgj Date: Thu Oct 17 15:15:58 2013 New Revision: 42983 URL: http://svnweb.freebsd.org/changeset/doc/42983 Log: - Fixes to the 2013Q3 report Submitted by: wblock, bjk Modified: head/en_US.ISO8859-1/htdocs/news/status/report-2013-07-2013-09.xml Modified: head/en_US.ISO8859-1/htdocs/news/status/report-2013-07-2013-09.xml ============================================================================== --- head/en_US.ISO8859-1/htdocs/news/status/report-2013-07-2013-09.xml Thu Oct 17 12:28:08 2013 (r42982) +++ head/en_US.ISO8859-1/htdocs/news/status/report-2013-07-2013-09.xml Thu Oct 17 15:15:58 2013 (r42983) @@ -175,46 +175,46 @@ </links> <body> - <p>Last year's high-performance storage vendors reported a + <p>Last year's high-performance storage vendor summit reported a performance bottleneck in the &os; block storage subsystem, - limiting peak performance around 300-500K IOPS. While that is - still more than enough for average systems, detailed + limiting peak performance to around 300-500K IOPS. While that + is still more than enough for average systems, detailed investigation has shown a number of places that require radical - improvement. Unmapped I/O support implemented early this year - already improved I/O performance by about 30% and moved more - accents toward GEOM and CAM subsystems scalability. Fixing + improvement. The unmapped I/O support implemented early this + year has already improved I/O performance by about 30% and moved + more focus toward GEOM and CAM subsystems scalability. Fixing these issues was the goal of this project.</p> - <p>The existing GEOM design assumed most I/O handling to be done - by only two kernel threads (<tt>g_up()</tt> and + <p>The existing GEOM design assumed most I/O handling was to be + done by only two kernel threads (<tt>g_up()</tt> and <tt>g_down()</tt>). That simplified locking in some cases, but limited potential SMP scalability and created additional scheduler overhead. This project introduces the concept of direct I/O dispatch into GEOM for cases where it is known to be safe and efficient. That implies marking some GEOM consumers and providers with one or two new flags, declaring situations - when a direct function call can be used instead of normal request - queuing. That allows avoiding any context switches inside GEOM - for the most widely used topologies, simultaneously processing - multiple I/Os from multiple calling threads.</p> - - <p>Having GEOM passing through multiple concurrent calls down to - the underlying layers exposed major lock congestion in CAM. In - the existing CAM design all devices connected to the same ATA/SCSI - controller are sharing a single lock, which can be quite busy due - to multiple controller hardware accesses and/or code logic. + when a direct function call can be used instead of normal + request queuing. That permits avoiding any context switches + inside GEOM for the most widely used topologies, simultaneously + processing multiple I/Os from multiple calling threads.</p> + + <p>Having GEOM pass through multiple concurrent calls down to the + underlying layers exposed major lock congestion in CAM. In the + existing CAM design, all devices connected to the same ATA/SCSI + controller share a single lock, which can be quite busy due to + multiple controller hardware accesses and/or code logic. Experiments have shown that applying only the above GEOM direct dispatch changes burns up to 60% of system CPU time or even more in attempts to obtain these locks by multiple callers, killing - any benefits of GEOM direct dispatch. To overcome that, new + any benefits of GEOM direct dispatch. To overcome that, a new fine-grained CAM locking design was implemented. It implies - splitting big per-SIM locks into several smaller ones: per-LUN - locks, per-bus locks, queue locks, etc. After these changes, - the remaining per-SIM lock protects only the controller driver - internals, reducing lock congestion down to an acceptable level - and keeping keep compatibility with existing drivers.</p> + splitting the big per-SIM locks into several smaller ones: + per-LUN locks, per-bus locks, queue locks, etc. After these + changes, the remaining per-SIM lock protects only the controller + driver internals, reducing lock congestion down to an acceptable + level and keeping compatibility with existing drivers.</p> - <p>Together, GEOM and CAM changes double the peak I/O rate, + <p>Together, the GEOM and CAM changes double the peak I/O rate, reaching up to 1,000,000 IOPS on contemporary hardware.</p> <p>The changes were tested by a number of people and will be @@ -249,10 +249,11 @@ </links> <body> - <p>A port of the OpenBSD <tt>vmx(4)</tt> ethernet driver has been - committed. The driver can be used in place of the VMware Tools - <tt>vmxnet3</tt> driver, which currently does not support - 10.0-RELEASE (or anything past 9.0-RELEASE).</p> + <p>A port of the OpenBSD <tt>vmx(4)</tt> ethernet driver for + VMware virtual machines has been committed. The driver can be + used in place of the VMware Tools <tt>vmxnet3</tt> driver, which + currently does not support 10.0-RELEASE (or anything past + 9.0-RELEASE).</p> </body> <help> @@ -305,35 +306,35 @@ <body> <p>We are currently working on cleaning up the - <tt>lang/python*</tt> ports to improve the compatibility with - the original upstream build behaviour and to lower the need for + <tt>lang/python*</tt> ports to improve their compatibility with + the original upstream build behaviour and to reduce the need for &os;-specific build patches. A first step was made in September by reducing the flags injected into the different Python interpreter versions.</p> - <p>The first tasks for supporting the installation of packages for - different Python ports have been done. A new metaport structure - has replaced the original Python port behaviour and will be + <p>The first tasks have been completed to support the installation + of packages for different Python ports. A new metaport structure + has replaced the original Python port behaviour, and will be enhanced over the next months to enable improved installation support of packages for different Python versions at the same time.</p> - <p>The Python ports framework was enhanced by automated packaging - list creation and replacement macros, which improve the + <p>The Python ports framework was enhanced with automated + packaging list creation and replacement macros, which improve the compatibility with multiple Python versions and reduce the packaging list sizes.</p> <p>PyPy was heavily enhanced over the last couple of months. - Major updates of the port solved integration issues and a new + Major updates to the port solved integration issues and a new <tt>pypy-devel</tt> port for snapshots and previews was added. Since the PyPy 3 release, there is a new <tt>pypy3-devel</tt> port available to provide not only compatibility for Python 2.x specific scripts, but also for those using the 3.x language specification.</p> - <p>IronPython found its way into the &os; ports tree, which - provides an implementation of the Python language based on .NET - and Mono.</p> + <p>IronPython found its way into the &os; ports tree, providing an + implementation of the Python language based on .NET and + Mono.</p> </body> <help> @@ -373,14 +374,14 @@ </links> <body> - <p>The <tt>entities</tt> project branch has been succesfully + <p>The <tt>entities</tt> project branch has been successfully merged into the main documentation branch per revision 42226 of the <tt>doc</tt> repository (see link). The purpose of this branch was to remove the duplicated definitions of authors in both <tt>authors.ent</tt> and <tt>developers.ent</tt>. The latter file has been removed after migrating its contents to the former file. While most changes are not visible to end users, - the Committers Guide was changed to accomodate for changes + the Committer's Guide was changed to accomodate for changes related to adding a new committer. Translators were also informed of the update. The largest hurdle mentioned in the last report, processing the <tt><email></tt> element, was @@ -498,9 +499,9 @@ <body> <p>A few years ago, Ada-based ports almost completely disappeared - from the Ports Collection. This was not surprising as + from the Ports Collection. This was not surprising, as FSF GNAT, the only open-source Ada compiler, ceased to - build correctly on any BSD flavor and previously built bootstrap + build correctly on any BSD flavor. Previously-built bootstrap compilers would not run on modern &os;, and certainly not on amd64. The first step, see the link for details, was to patch GCC in order to fix GNAT not only on &os;, but DragonFly, @@ -508,28 +509,28 @@ amd64 platforms were produced during this effort. Ada compilers on &os; now pass 100% of the ACATS and GCC testsuites.</p> - <p>With the first new Ada compiler port was introduced, the + <p>With the introduction of the first new Ada compiler port, the GCC 4.6-based <tt>lang/gnat-aux</tt>, the GNAT Programming - Studio (multilanguage integrated development environment), - XML/Ada, and GTkAda were among the first Ada ports + Studio (a multilanguage integrated development environment), + XML/Ada, and GtkAda were among the first Ada ports resurrected.</p> <p>With the latest compiler, <tt>lang/gcc-aux</tt> based on GCC 4.7, a cohesive Ada framework was created with the new - <tt>USES=</tt> capability. Currently around 20 ports are part - of this framework including Florist, ASIS, GPRbuild, QtAda, + <tt>USES=</tt> framework. Currently around 20 ports are part of + this framework including Florist, ASIS, GPRbuild, QtAda, AdaControl, AdaBrowse, PolyOrb, and AWS (Ada Web Server).</p> <p>The GNAT AUX compiler is also still in use to serve as a basis for the GNATDroid ports which are &os;-to-Android Ada+C cross-compilers. - However, these will soon be integrated in the Ada Framework.</p> + However, these will soon be integrated into the Ada Framework.</p> - <p>At this point, it looks like that &os; (shared with DragonFly - via DPorts) has taken the crown from Debian as the recognized best + <p>At this point, it looks like &os; (shared with DragonFly via + DPorts) has taken the crown from Debian as the recognized best Ada development platform. The &os; versions of the software are more recent and the Ports Collection has ports not available on - Debian, such as LibSparkCrypto, Matreshka library, and the Ahven - unit tester.</p> + Debian, such as LibSparkCrypto, the Matreshka library, and the + Ahven unit tester.</p> <p>Future work potentially includes converting GCC AUX to GCC 4.8 to acquire better Ada 2012 support, importing @@ -557,9 +558,9 @@ <body> <p>Initial support of Allwinner A20 SoC is committed to - <tt>head</tt>. A20 SoC on Cubieboard2 is pin-to-pin compatible - with A10 in Cubieboard1 and &os; supports the following - peripherals:</p> + <tt>head</tt>. The A20 SoC on Cubieboard2 is pin-to-pin + compatible with the A10 in Cubieboard1 and &os; supports the + following peripherals:</p> <ul> <li>USB EHCI</li> @@ -715,20 +716,20 @@ <body> <p>The ARM architecture is becoming more and more prevalent, with - increasing usage beyond the mobile and embedded space. Among the - more interesting industry trends emerging in the recent months, - there has been the concept of "ARM server". Some top-tier - companies, e.g. Dell and HP, have already started to develop - such systems.</p> + increasing usage beyond the mobile and embedded space. Among + the more interesting industry trends emerging in the recent + months, there has been the concept of "ARM server". Top-tier + companies like Dell and HP have already started to develop such + systems.</p> - <p>Key to success of &os; in these new areas is dealing with the - sophisticated features of the platform, for example adding + <p>Key to the success of &os; in these new areas is dealing with + the sophisticated features of the platform, for example adding support for superpages.</p> <p>The objective of this project is to enable &os;/arm to utilize - superpages which would allow efficient use of TLB translations - (by enlarging TLB coverage), leading to improved performance in - many applications and scalability. This is intended to work on + superpages, allowing efficient use of TLB translations (by + enlarging TLB coverage), leading to improved performance in many + applications and scalability. This is intended to work on ARMv7-based processors, however compatibility with ARMv6 will be preserved.</p> @@ -832,16 +833,15 @@ <p>Due to the quickly approaching time of 10.0-RELEASE, the priorities for the native iSCSI stack shifted somewhat, from performance optimizations to making sure the new stack is - reliable, feature-complete and is able to interoperate correctly + reliable, feature-complete, and is able to interoperate correctly with various implementations. Plenty of time was invested into testing and debugging, mostly on the initiator side, to make sure it works correctly with other targets, such as Solaris - COMSTAR, and behaves properly in edge conditions, e.g. in case - of connection problems. Nevertheless, some fundamental - optimizations, such as Immediate Data support, were implemented. - Also, the documentation has improved, and there is going to be a - new section added to the &os; Handbook that describes the use of - the new stack.</p> + COMSTAR, and behaves properly in edge conditions like connection + problems. Nevertheless, some fundamental optimizations, such as + Immediate Data support, were implemented. The documentation has + improved, and there will be a new section added to the &os; + Handbook describing the use of the new stack.</p> <p>The new stack was committed to <tt>head</tt> and will ship as part of 10.0-RELEASE. There is ongoing work on fixing issues @@ -875,21 +875,22 @@ </links> <body> - <p>SDIO is an interface designed as an extension for the existing + <p>SDIO is an interface designed as an extension of the existing SD card standard, to allow connecting different peripherals to the host with the standard SD controller. Peripherals currently sold at the general market include WLAN/BT modules, cameras, - fingerprint readers, barcode scanners. The driver is + fingerprint readers, and barcode scanners. The driver is implemented as an extension to the existing MMC bus, adding a lot of new SDIO-specific bus methods. A prototype of the driver - for Marvell SDIO WLAN/BT (Avastar 88W8787) module is also being - developed, using the existing Linux driver as the reference.</p> + for the Marvell SDIO WLAN/BT (Avastar 88W8787) module is also + being developed, using the existing Linux driver as the + reference.</p> <p>SDIO card detection and initialization already work, most needed bus methods are implemented and tested. There is an - ongoing work to design a good locking model for the stack. WiFi - driver is able to load a firmware onto the card and initialize - it.</p> + ongoing work to design a good locking model for the stack. The + WiFi driver is able to load firmware onto the card and + initialize it.</p> </body> <help> @@ -902,8 +903,8 @@ receiving data, network scanning, and so on).</task> <task>Implement detach path. It cannot be tested on the DreamPlug - used for development, because it does not have an external - SDIO-capable slot.</task> + used for development, because the DreamPlug does not have an + external SDIO-capable slot.</task> </help> </project> @@ -928,7 +929,7 @@ <p>If threads or signal handlers call <tt>fork()</tt> and <tt>exec()</tt>, file descriptors may be passed undesirably to child processes, which may lead to hangs (if a pipe is not - closed), exceeding the file descriptor limit and security + closed), exceeding the file descriptor limit, and security problems (if the child process has lower privilege). One solution is various new APIs that set the "close-on-exec" flag atomically with allocating a file descriptor. Some existing @@ -978,15 +979,15 @@ </contact> <body> - <p>Random numbers require a lot more thought and preparation that + <p>Random numbers require a lot more thought and preparation than would naively appear to be the case. For simulations, number sequences that are repeatable but sufficiently disordered are - often what is required to achieve required experimental - duplication ability, and many programmers are familiar with - these. For cryptography, it is essential that an attacker not - be able to predict or guess the output sequence, thus giving a - source of security-critical secret material for uses such as - passwords or "key material".</p> + often needed to achieve required experimental duplication + ability, and many programmers are familiar with these. For + cryptography, it is essential that an attacker not be able to + predict or guess the output sequence, thus giving a source of + security-critical secret material for uses such as passwords or + "key material".</p> <p>&os;'s random number generator, available as the pseudo-file <tt>/dev/random</tt> produces unpredictable numbers intended for @@ -1046,7 +1047,7 @@ <body> <p>GNUstep is the open source implementation of the Objective-C APIs based on the OpenStep specification that Apple brands as - Cocoa. The similarities between &os; and OS X + Cocoa. The similarities between the &os; and OS X <tt>libc</tt> make &os; an attractive target platform for porting OS X applications, with the addition of GNUstep.</p> @@ -1089,8 +1090,8 @@ </links> <body> - <p>LLDB is the the debugger project in the LLVM family. It - supports the Mac OS X, Linux, and &os; platforms.</p> + <p>LLDB is the debugger project in the LLVM family. It supports + the Mac OS X, Linux, and &os; platforms.</p> <p>A number of improvements have been made to the port since the previous status update. Unit test failures have been triaged @@ -1243,7 +1244,7 @@ 10.0.</p> <p><tt>libnv</tt>, used for communication between Casper services - and consumers, but hopefully will be used more widely, is + and consumers, but which will hopefully be used more widely, is finalized and comes with a nice set of regression tests.</p> <p>The number of applications sandboxed using the Capsicum @@ -1261,11 +1262,12 @@ <task>Finish documentation for <tt>libnv</tt>.</task> <task>Start making <tt>libc</tt> more sandbox-friendly, that is, - functions such as <tt>strerror(3)</tt>, <tt>strsignal(3)</tt>, - <tt>localtime(3)</tt>, <tt>login_get*()</tt>, - <tt>getservent(3)</tt>, <tt>getprotent(3)</tt>, - <tt>getrpcent(3)</tt> open files on first use, which might be - too late if we are already in a capability-mode sandbox.</task> + modifying functions such as <tt>strerror(3)</tt>, + <tt>strsignal(3)</tt>, <tt>localtime(3)</tt>, + <tt>login_get*()</tt>, <tt>getservent(3)</tt>, + <tt>getprotent(3)</tt>, and <tt>getrpcent(3)</tt> which + currently open files on first use, which might be too late if we + are already in a capability-mode sandbox.</task> <task>Rethink the <tt>system.filesystem</tt> Casper service to allow for easy compartmentalization of various command-line @@ -1339,7 +1341,7 @@ <body> <p>The &os; Documentation Project Primer had not changed at the same rate as the documents themselves. Some sections were - outdated, others were wordy and confusing, while information on + outdated and others were wordy and confusing, while information on new changes to the documentation were not described at all. In July, Warren gave the entire FDP Primer a fairly intense edit for simplicity and clarity. Chapters and sections were moved @@ -1371,25 +1373,25 @@ </contact> <body> - <p>There are some things going on with &os;/sparc64 port behind - the scenes.</p> + <p>There are some things going on with the &os;/sparc64 port + behind the scenes.</p> <p>For one, after having fixed all remaining problems and starting with 9.2-RELEASE, release bits for this architecture are cross-built on the &os; Project cluster. As one might already have noticed, this means that from now on, sparc64 install sets and images including those for ALPHA, BETA, and RC builds, are - already available along with those for the other platforms + already available alongside those for the other platforms supported by &os;. It also means that since August 2013, automatically cross-built monthly &os;/sparc64 snapshots are distributed via the official project mirrors. Hopefully, this - can be soon extended further with <tt>freebsd-update(8)</tt> + can soon be extended further with <tt>freebsd-update(8)</tt> support for sparc64.</p> <p>Second, the X.Org ports have been fixed to work on sparc64 when - built with <tt>WITH_NEW_XORG</tt> knob. However, it still needs - to be evaluated whether the recently committed update to Mesa - 9.1.6 has introduced any breakage.</p> + built with the <tt>WITH_NEW_XORG</tt> knob. However, it still + needs to be evaluated whether the recently committed update to + Mesa 9.1.6 has introduced any breakage.</p> </body> </project> @@ -1416,14 +1418,14 @@ <body> <p>The ports tree contains approximately 24,400 ports, while the - PR count exceeds 1,900. In third quarter, we added four new - committers and took in six commit bits for safe keeping.</p> + PR count exceeds 1,900. In the third quarter, we added four new + committers and took in six commit bits for safekeeping.</p> <p>A significant amount of effort has gone into tweaking and - manipulating the infrastructure to modernise, and update it, in - preperation for <tt>pkg(8)</tt> replacing the old <tt>pkg_*</tt> - infrastructure, as well as preparing for &os; and Clang as - default compiler.</p> + manipulating the infrastructure to modernize and update it, in + preperation for <tt>pkg(8)</tt> replacing the old + <tt>pkg_add(1)</tt> infrastructure, as well as preparing for + &os; with Clang as default compiler.</p> <p>Automated procedures for Quality Assurance have been implemented, notably <tt>pkg-fallout</tt>. All porters are @@ -1431,8 +1433,8 @@ links), and do their part to fix ports for <tt>pkg(8)</tt> and Clang readiness.</p> - <p>Many iterations of tests were run to ensure the maximum amount - of packages would be available for the 9.2 release.</p> + <p>Many iterations of tests were run to ensure that as many + packages as possible would be available for the 9.2 release.</p> </body> <help> @@ -1457,12 +1459,12 @@ official <tt>pkg(8)</tt> repository, in cooperation with the Port Management Team, the Security Team, and the Cluster Administration Team. At the same time, there are plans to - gradually deprecate the use of the old pkg_tools, allowing - <tt>pkg(8)</tt> to be the default binary package management - solution for &os;, arriving with 10.0-RELEASE. Thomas Abthorpe - has been appointed to the role of liaison between the Core Team - and the Ports Management Team, in order to make the - collaboration more effective.</p> + gradually deprecate the use of the old <tt>pkg_add(1)</tt>, + allowing <tt>pkg(8)</tt> to be the default binary package + management solution for &os;, arriving with 10.0-RELEASE. + Thomas Abthorpe has been appointed to the role of liaison + between the Core Team and the Ports Management Team, in order to + make the collaboration more effective.</p> <p>David Chisnall has joined the group that publishes the Quarterly Status reports and compiled a special status report on @@ -1474,7 +1476,7 @@ <p>There were src commit bits issued for 5 new developers and most of the src commits being idle more than 12 months have been - taken into safekeeping as result of a major cleanup in the + taken into safekeeping as result of a major cleanup to the repository access file in July, performed by Gavin Atkinson.</p> </body> </project> @@ -1506,9 +1508,9 @@ <p>The <tt>radeonkms</tt> driver was committed to &os; <tt>head</tt> in the end of August and will be part of 10.0-RELEASE. It received several fixes since the initial - commit and now it seems quite stable. However, one missing - major feature is support for suspend/resume: the GPU almost - always locks up during resume on the test computer.</p> + commit and now seems quite stable. However, one missing major + feature is support for suspend/resume: the GPU almost always + locks up during resume on the test computer.</p> <p>Thanks to the update of Mesa and the update of <tt>x11-drivers/xf86-video-ati</tt> to 7.2.0 @@ -1530,8 +1532,8 @@ <li>Fixes in the framebuffer code, which would help the future deployment of Newcons.</li> - <li>Preliminary support for minor devices (that is, control vs. - render nodes).</li> + <li>Preliminary support for minor devices (that is, control + versus render nodes).</li> <li>Support for <tt>setmaster</tt> and <tt>dropmaster</tt>, which allows to run multiple X sessions.</li> @@ -1604,7 +1606,8 @@ BIOS services.</p> <p>This project was originally started by Ed Schouten, and it - already featured the following (among many others) in 2013:</p> + already featured the following features (among many others) in + 2013:</p> <ul> <li>Unicode fonts with Latin, Cyrillic and some more simple @@ -1623,12 +1626,13 @@ history. The old, separate history buffer has been removed.</li> - <li>The history is implemented by a circular buffer, that is, no buffer - overflows, scrolling is "unlimited".</li> + <li>The history is implemented by a circular buffer which has no + risk of overflow, and scrolling appears "unlimited".</li> - <li><tt>VT_PROCESS</tt> mode, a way to hold the terminal. For - example, X.Org uses this feature to prevent the user from - switching terminals.</li> + <li><tt>VT_PROCESS</tt> mode, a way to hold the terminal and + prevent terminal switching. For example, X.Org uses this + feature to prevent the user from switching to a non-X + terminal.</li> <li><tt>drm2/fb_helper</tt>, the KMS driver. This binds Newcons to framebuffers created the DRM-enabled video drivers in the
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201310171515.r9HFFxcM056558>