svn commit: r48752 - head/en_US.ISO8859-1/htdocs/news/status
Benjamin Kaduk
bjk at FreeBSD.org
Sun May 1 02:31:21 UTC 2016
Author: bjk
Date: Sun May 1 02:31:19 2016
New Revision: 48752
URL: https://svnweb.freebsd.org/changeset/doc/48752
Log:
Belatedly finish my editing pass through the 2016Q1 report
Modified:
head/en_US.ISO8859-1/htdocs/news/status/report-2016-01-2016-03.xml
Modified: head/en_US.ISO8859-1/htdocs/news/status/report-2016-01-2016-03.xml
==============================================================================
--- head/en_US.ISO8859-1/htdocs/news/status/report-2016-01-2016-03.xml Sun May 1 00:05:40 2016 (r48751)
+++ head/en_US.ISO8859-1/htdocs/news/status/report-2016-01-2016-03.xml Sun May 1 02:31:19 2016 (r48752)
@@ -671,16 +671,16 @@
</links>
<body>
- <p>A new implementation for support of native PCI-express
+ <p>A new implementation of support for native PCI-express
hotplug is present at the URL above. Much of the new code
lives in the PCI-PCI bridge driver to handle hotplug events
and manage the PCI-express slot registers. Additional changes
in the branch include adding new <tt>rescan</tt> and
- <tt>delete</tt> commands to <tt>devctl(8)</tt> as well as
+ <tt>delete</tt> commands to <tt>devctl(8)</tt>, as well as
support for rescanning PCI busses.</p>
<p>The current implementation has been tested on systems with
- ExpressCard but could use additional testing, especially on
+ ExpressCard slots but could use additional testing, especially on
systems with other PCI-express HotPlug features such as
mechanical latches, attention buttons, indicators, and so
on.</p>
@@ -688,7 +688,7 @@
<help>
<task>
- <p>Split branch into separate logical changes as commit
+ <p>Split the branch into separate logical changes as commit
candidates.</p>
</task>
@@ -699,11 +699,11 @@
</project>
<project cat='ports'>
- <title>KDE on FreeBSD</title>
+ <title>KDE on &os;</title>
<contact>
<person>
- <name>KDE on FreeBSD team</name>
+ <name>KDE on &os; team</name>
<email>kde at FreeBSD.org</email>
</person>
</contact>
@@ -717,8 +717,8 @@
</links>
<body>
- <p>The KDE on FreeBSD team focuses on packaging and making sure
- that the experience of KDE and Qt on FreeBSD is as good as
+ <p>The KDE on &os; team focuses on packaging and making sure
+ that the experience of KDE and Qt on &os; is as good as
possible.</p>
<p>While the list of updates is shorter than that for the
@@ -732,7 +732,7 @@
highlight in the beginning of this year is the (re)addition of
another committer to our experimental repository: Adriaan de
Groot, a longtime KDE contributor who also used to work on KDE
- and FreeBSD almost a decade ago when our team was first
+ and &os; almost a decade ago when our team was first
formed. Welcome back, Ade!</p>
<p>The following big updates were landed in the ports tree this
@@ -760,7 +760,7 @@
<p>Work on Qt 5.6.0 is
under way in our experimental repositories. At
- the time of writing, it also contains KDE Frameworks 5.20.0,
+ the time of this writing, it also contains KDE Frameworks 5.20.0,
Plasma 5.6.1, and KDE Applications 16.03.80.</p>
<p>Users interested in testing those ports are encouraged to
@@ -802,7 +802,7 @@
<p>POSIX specifies several kinds of <tt>pthread</tt> locks. For
this report, the private and process-shared variants are
considered. Private locks can be used only by the threads of
- the same process, which share the address space.
+ the same process, which share a single common address space.
Process-shared locks can be used by threads from any process,
assuming the process can map the lock memory into its address
space.</p>
@@ -813,7 +813,7 @@
address of the actual structure carrying the lock. This has
unfortunate consequences for implementing the
<tt>PTHREAD_PROCESS_SHARED</tt> attribute for locks, since
- really only the pointer is shared when the lock is mapped into
+ really only the pointer is shared when a lock is mapped into
distinct address spaces.</p>
<p>A common opinion was that we have no choice but to break the
@@ -825,12 +825,12 @@
<p>Instead, I proposed and implemented a scheme where
process-shared locks can be implemented without breaking the
- ABI. The lock memory is used as a key into the system-global
- hash of the shared memory objects (off-pages), which carry the
- real lock structures.</p>
+ ABI. The lock memory is used as a key into a system-global
+ hash of shared memory objects (off-pages), which contain the
+ actual lock structures.</p>
- <p>New <tt>umtx</tt> operations to create or look up the shared
- object, by the memory key were added. <tt>libthr</tt> is
+ <p>New <tt>umtx</tt> operations to create or look up a shared
+ object by memory key were added. <tt>libthr</tt> is
modified to look up the object and use it for shared locks,
instead of using <tt>malloc()</tt> as for private locks.</p>
@@ -840,13 +840,13 @@
<p>The proposal of inlining the lock structures, besides the
drawbacks of breaking ABI, has its merits. Most important,
- the inlining avoids the need of indirection. Another
- important advantage over the off-page page approach is that no
+ the inlining avoids the need for indirection. Another
+ important advantage over the off-page approach is that no
off-page object needs to be maintained, and the lifecycle of
the shared lock naturally finishes with the destruction of the
- shared memory without explicit cleanup. Right now, off-pages
+ shared memory, without need for explicit cleanup. Right now, off-pages
hook into vm object termination to avoid leakage, but
- long-livedness of the vnode vm object prolonges the off-page
+ long-livedness of the vnode vm object prolonges the off-page's
existence for shared locks backed by files, however unlikely
they may be.</p>
@@ -882,33 +882,33 @@
<body>
- <p>
- <ul>
- <li>migrated services out of the hosting space in ISC
- (peter, sbruno)</li>
+ <p>This quarter, we:</p>
+ <ul>
+ <li>migrated services out of the hosting space in ISC
+ (peter, sbruno)</li>
- <li>began migration of services into RootBSD hosting space
- (peter, sbruno)</li>
+ <li>began migration of services into the RootBSD hosting space
+ (peter, sbruno)</li>
- <li>collaborated with phabricator admin team to migrate to
- new and improved host in NYI. (AllanJude, peter,
- sbruno)</li>
+ <li>collaborated with the phabricator admin team to migrate to
+ a new and improved host in NYI. (allanjude, peter,
+ sbruno)</li>
- <li>installed new and beefier Jenkins machine(gnn, lwshu,
- sbruno)</li>
+ <li>installed a new and beefier Jenkins machine (gnn, lwshu,
+ sbruno)</li>
- <li>still looking for more Asian mirrors for pkg,svn,ftp
- (Japan, India). (sbruno)</li>
+ <li>are still looking for more Asian mirrors for pkg, svn, and ftp
+ (Japan, India). (sbruno)</li>
- <li>migration of Taiwanese mirror to new location completed.
- (lwshu)</li>
+ <li>completed the migration of the Taiwanese mirror to its new location.
+ (lwshu)</li>
- <li>clang/llvm buildbbot now hosted in the FreeBSD cluster
- at NYI (sbruno, emaste)</li>
+ <li>started hosting a clang/llvm buildbbot in the &os; cluster
+ at NYI (sbruno, emaste)</li>
- <li>resolved UK mirror outage with Bytemark (gavin,
- peter)</li>
- </ul></p>
+ <li>resolved a UK mirror outage with Bytemark (gavin,
+ peter)</li>
+ </ul>
</body>
</project>
@@ -928,17 +928,17 @@
<body>
<p>Ruby on Rails is the base for most of the rubygems in the
- portstree. Currently version 3.2 and 4.2 coexists, but since
- Rails 3.2 runs out of support, the time has come to
+ Ports Collection. Currently, versions 3.2 and 4.2 coexist, but since
+ Rails 3.2 is running out of support, the time has come to
switch.</p>
<p>There is an ongoing progress to remove Rails 3.2 from the
ports tree. While many gems already work with the new
- version, there are some exceptions. For example www/redmine
- needs a big update (which is currently tested) because it
- depends on gems which therefore depends on Rails 3.2.</p>
+ version, there are some exceptions. For example, www/redmine
+ needs a big update (which is currently being tested) because it
+ depends on gems that depends on Rails 3.2.</p>
- <p>If you want to help porting or testing, feel free to contact
+ <p>If you want to help with porting or testing, feel free to contact
me or the mailinglist <tt>ruby at FreeBSD.org</tt>.</p>
</body>
</project>
@@ -960,7 +960,7 @@
<body>
<p>After nearly a year of work on this project, GitLab 8.5.5 was
committed into the ports tree. A big thanks to the enormous
- number of people involved! Since GitLab is a fast moving
+ number of people involved! Since GitLab is a fast-moving
project, there is also ongoing work to stay in sync with
upstream. Have fun!</p>
</body>
@@ -981,15 +981,15 @@
<body>
- <p>Build improvements for buildworld on <em>head</em> continue.
+ <p>Build improvements for buildworld on &os; head continue.
Some highlights include:</p>
<ul>
- <li><tt>WITH_FAST_DEPEND</tt> was made default in r296668 and
+ <li><tt>WITH_FAST_DEPEND</tt> was made the default in r296668, and
later made the only option in r297434. The new depend code
avoids a <tt>make depend</tt> tree walk and generates
- <tt>.depend</tt> files during build as a side-effect of
- compiling. This is using the <tt>-MF</tt> flags of the
+ <tt>.depend</tt> files during the build as a side-effect of
+ compilation. This is done by using the <tt>-MF</tt> flags of the
compiler. This speeds up the build by 15-35%.</li>
<li><a href="http://bugs.freebsd.org/196193">PR 196193</a>:
@@ -1055,18 +1055,18 @@
<tt>bmake</tt> stores filemon's output in a <tt>.meta</tt>
file along with the build command and later uses this to
trigger a rebuild of the target if any of the files referenced
- are missing or modified or if the build command changes. It
- provides the same functionality as compiler <tt>-MF</tt> flags
+ are missing or modified, or if the build command changes. It
+ provides the same functionality as the compiler's <tt>-MF</tt> flag,
but for everything. It will be critical for buildworld's
<tt>WITH_META_MODE</tt> (which is the normal buildworld but
- just using filemon) to provide a reliable incremental build
- without even the need of <tt>.depend</tt> files or compiler
+ only using filemon) to provide a reliable incremental build
+ without even the need for <tt>.depend</tt> files or compiler
<tt>-MF</tt> flags. This allows <tt>-DNO_CLEAN</tt> to work
all of the time.</p>
<p>Filemon on -HEAD was improved for stability and performance
over this quarter. It no longer causes every syscall it hooks
- into to loop on processes looking for a matching filemon
+ into to loop over processes looking for a matching filemon
struct. It now just attaches directly to the struct proc with
its own pointer. This improves performance by reducing lock
contention during a build. Much other work went into
@@ -1082,15 +1082,15 @@
<help>
<task>
- <p>Improving credential handling</p>
+ <p>Improve credential handling.</p>
</task>
<task>
- <p>Improving EVENTHANDLER performance</p>
+ <p>Improve EVENTHANDLER performance.</p>
</task>
<task>
- <p>Possibly providing a framework for syscallenter/syscallret
+ <p>Possibly provide a framework for syscallenter/syscallret
hooking to avoid the need to hook syscalls as Filemon
does.</p>
</task>
@@ -1115,24 +1115,23 @@
</links>
<body>
- <p>A continuation of the Book-E QorIQ support enhancements by
- Semihalf dating back to 2012.</p>
+ <p>This project is a continuation of the Book-E QorIQ support
+ enhancements by Semihalf dating back to 2012.</p>
- <p>The AmigaOne X5000 series of AmigaOS compatible systems uses
+ <p>The AmigaOne X5000 series of AmigaOS-compatible systems uses
the Freescale QorIQ series of SoCs for a desktop-class form
factor. The work here entails adding support for the e5500
core itself, in addition to support for the SoC
peripherals.</p>
- <p>Currently most code is checked in to enable basic support:
- dTSEC (ethernet), core support (e500mc, e5500). As part of
+ <p>Currently, most of the code to enable basic support is checked
+ in: dTSEC (ethernet), core support (e500mc, e5500). As part of
this, <tt>rman</tt>, the kernel resource manager, was enhanced
- to use <tt>uintmax_t</tt> for resources. This allows devices
- to be physically above the 4GB boundary on 32-bit systems.
- With a statically compiled device tree, it boots to multiuser
- mode with nfsroot, and can be used as normal (serial and SSH
- logins once configured).</p>
- </body>
+ to use <tt>uintmax_t</tt> for resources. This allows devices to
+ be physically above the 4GB boundary on 32-bit systems. With a
+ statically compiled device tree, it boots to multiuser mode with
+ nfsroot, and can be used as normal (serial and SSH logins once
+ configured).</p> </body>
<sponsor>Alex Perez (Inertial Computing)</sponsor>
@@ -1155,7 +1154,7 @@
<task>
<p>Local console (VGA) support: It currently boots with a
- serial console. vgapci0 is seen if there is a PCIe graphics
+ serial console. <tt>vgapci0</tt> is seen if there is a PCIe graphics
card, but <tt>vt(4)</tt> does not attach to it yet.</p>
</task>
@@ -1220,14 +1219,14 @@
</links>
<body>
- <p>The FreeBSD German Documentation Project translates FreeBSD's
+ <p>The FreeBSD German Documentation Project translates &os;'s
documentation (handbook, articles, website, etc.) into the
German language.</p>
<p>Due to the tireless effort of Björn Heidotting, we made huge
improvements in catching up with the translation of the German
handbook. Benedict helped with reviewing the changes using
- FreeBSD's review system Phabricator, which helped a lot. We
+ &os;'s review system Phabricator, which helped a lot. We
now have the following handbook chapters in sync with the
latest version in the English tree:</p>
@@ -1291,14 +1290,14 @@
projects, even if we do not require it in order to
update &os;.</p>
- <p>In the first quarter of 2016 The ELF Tool Chain tools were
- updated to a snapshot of upstream SVN revision 3400, which
+ <p>In the first quarter of 2016, the ELF Tool Chain tools were
+ updated to a snapshot of upstream Subversion revision 3400, which
is close to the 0.7.1 release. Additional bug fixes were
- committed to FreeBSD and subsequently merged into the upstream
+ committed to &os; and subsequently merged into the upstream
repository.</p>
<p>ELF Tool Chain's <tt>elfcopy(1)</tt> is now installed as
- <tt>objcopy(1)</tt> by default as it is a viable replacement
+ <tt>objcopy(1)</tt> by default, as it is a viable replacement
for the base system and ports tree.</p>
<p>Significant improvements were made to the
@@ -1307,7 +1306,7 @@
AArch64 support.</p>
</body>
- <sponsor>The &os; Foundation</sponsor>
+ <sponsor>The FreeBSD Foundation</sponsor>
<help>
<task>
@@ -1319,8 +1318,8 @@
</task>
<task>
- <p>Investigate replacement objdump, ld and as
- implementations.</p>
+ <p>Investigate replacement <tt>objdump</tt>, <tt>ld</tt> and
+ <tt>as</tt> implementations.</p>
</task>
</help>
</project>
@@ -1345,7 +1344,7 @@
<body>
<p>Mellanox is working on a big infiniband update towards
Mellanox OFED v3.2 of the infiniband stack in &os;. The
- updates include both userland and kernel.
+ updates include both userland and kernel components.
Infiniband patches for &os; are available in the link above
which can be downloaded and applied to a recent &os;-head
checkout.</p>
@@ -1402,35 +1401,35 @@
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. The collection of drivers
- that are required to use Hyper-V synthetic devices in FreeBSD
+ that are required to use Hyper-V synthetic devices in &os;
are known as FreeBSD Integration Services (BIS). Some of the
BIS drivers (like network and storage drivers) have existed in
FreeBSD 9.x and 10.x for years, but there are still some
performance and stability issues and bugs. Compared with
Windows and Linux VMs, the current BIS lacks some useful
features, e.g., live virtual machine backup, TRIM/Unmap, the
- support for UEFI VM (boot from UEFI), etc.</p>
+ support for UEFI VMs (boot from UEFI), etc.</p>
<p>During the past quarter, we made a great progress on the
performance tuning for Hyper-V network driver. We also
refactored and cleaned up the VMBus driver, and fixed some
- important bugs. All the work makes FreeBSD VMs run even
+ important bugs. All the work makes &os; VMs run even
better on Hyper-V and the Hyper-V based cloud platform
Azure!</p>
<p>Our work during 2016Q1 is documented below:</p>
- <p>Optimizing the performance of Hyper-V network driver</p>
+ <p>Optimizing the performance of Hyper-V network driver:</p>
<ul>
- <li>We added the LRO (Large Receive Offloading) support to the
- driver and properly handled the ACK packets. This
- effectively reduced the CPU cycles used in the TCP/IP stack
- and dramatically boosted the network performance!</li>
+ <li>We added LRO (Large Receive Offloading) support to the
+ driver and properly handle ACK packets. This
+ effectively reduces the CPU cycles used in the TCP/IP stack
+ and dramatically boosts network performance!</li>
- <li>We enabled the vRSS (virtual Receive Side Scaling) support
+ <li>We enabled vRSS (virtual Receive Side Scaling) support
for the driver. This greatly improved the network
- performance for SMP virtual machine (VM).</li>
+ performance for SMP virtual machines.</li>
<li>We used a separate Tx kernel thread to relieve the Rx
thread of transmitting packets (the Rx thread tried to
@@ -1438,82 +1437,87 @@
receive packets and send ACKs faster.</li>
<li>Now we can reach a VM-to-VM throughput of 9.1Gbps on a
- host with 10Gbps physical NIC, and over 20Gbps on a host
- with 40Gbps NIC, and meanwhile the CPUs still have plenty of
- cycles for applications.</li>
+ host with a 10Gbps physical NIC, and over 20Gbps on a host
+ with a 40Gbps NIC, all the while with plenty of CPU cycles
+ left for applications.</li>
- <li>We also enabled IP header checksum offloading, and RX
+ <li>We also enabled IP header checksum offloading, and Rx
checksum offloading for UDP.</li>
<li>Further performance tuning is working in progress.</li>
</ul>
- <p>Refactoring and Cleaning up the VMBus driver code</p>
+ <p>Refactoring and cleaning up the VMBus driver code:</p>
<ul>
- <li>Instead of using swi threads directly, now we use per-CPU
- taskqueue_create_fast() threads for event and message
- handling, making the code more FreeBSD conventional.</li>
+ <li>Instead of using <tt>swi</tt> threads directly, we now use per-CPU
+ <tt>taskqueue_create_fast()</tt> threads for event and message
+ handling, making the code more conventional for &os;.</li>
- <li>Made a lot of cleanup to the hv_utils code (HeartBeat,
+ <li>We did a lot of cleanup to the <tt>hv_utils</tt> code (HeartBeat,
TimeSync and Shutdown) and we are further cleaning up the
KVP code.</li>
- <li>Used a new message/interrupt slot for Hyper-V timer, so
+ <li>We used a new message/interrupt slot for the Hyper-V timer, so
the handling of timer and non-timer messages can be
distinguished, fixing a potential issue.</li>
<li>Instead of finding an available IDT vector by hacking,
- we are changing to use the normal method, that is,
+ we are changing to use the normal method,
<tt>lapic_ipi_alloc()</tt>.</li>
- <li>We are modularizing the Hyper-V modules: 1) they will be
- loaded in the loader; 2) we are going to enhance
- <tt>devd(8)</tt> to improve the hot plug case.</li>
+ <li>We are modularizing the Hyper-V modules:
+ <ol>
+ <li>they will be loaded in the loader;</li>
+ <li>we are going to enhance <tt>devd(8)</tt> to improve
+ the hot plug case.</li>
+ </ol>
+ </li>
</ul>
- <p>Bug Fixing</p>
+ <p>Bug Fixing:</p>
<ul>
- <li>Fixed the "spurious multiple disks" issue (PR 206630 ???
- FreeBSD 10.2 on Windows 10 and 2016 server may not boot due
- to multiple invalid disks issue) in the Hyper-V storage
- driver and now FreeBSD VM can reliably boot on Win10 and
- 2016 hosts.</li>
+ <li>Fixed the "spurious multiple disks" issue (PR
+ 206630 — &os; 10.2 on Windows 10 and 2016 server may not
+ boot due to multiple invalid disks) in the Hyper-V storage
+ driver and now &os; VMs can reliably boot on Win10 and 2016
+ hosts.</li>
- <li>Fixed the OACTIVE issue (PR 207297 - [Hyper-V] FreeBSD
+ <li>Fixed the OACTIVE issue (PR 207297 — [Hyper-V] FreeBSD
10.2 on hyperv lost network under heavy load for
OACTIVE).</li>
- <li>Fixed TSC calibration issue (PR 208238 - [Hyper-V] TSC
- frequency is not correctly detected: "calcru: runtime went
- backwards") and we will not see the "runtime went backwards"
- messages any more!</li>
+ <li>Fixed a TSC calibration issue (PR 208238 — [Hyper-V] TSC
+ frequency is not correctly detected: "calcru: runtime went
+ backwards") and we will not see the "runtime went
+ backwards" messages any more!</li>
- <li>Fixed the "very slow terminal" issue of 11-CURRENT by
+ <li>Fixed the "very slow terminal" issue of 11-CURRENT by
enabling text mode when we are running on hypervisors.</li>
- <li>Fixed the "unknown dhcp option value 0xf5" issue in
+ <li>Fixed the "unknown dhcp option value 0xf5" issue in
<tt>dhclient(8)</tt> by asking <tt>dhclient(8)</tt> to
- ignore the option and &os; VM on Azure can reliably get IP
- now.</li>
- </ul>
+ ignore the option, and &os; VMs on Azure can now reliably get
+ IP addresses.</li>
- <p>Found a workaround for PR 20824 ([Hyper-V] VM network may not
- work over virtual switch based on wireless NIC): add
- "net.link.ether.inet.max_age=60" in /etc/sysctl.conf.</p>
+ <li>Found a workaround for PR 20824 ([Hyper-V] VM network may not
+ work over virtual switch based on wireless NIC): add
+ "net.link.ether.inet.max_age=60" in
+ /etc/sysctl.conf.</li>
+ </ul>
<p>We plan to add support for live virtual machine backup,
TRIM/Unmap, and UEFI VMs (Hyper-V Generation-2 VMs).</p>
<p>We published errata (FreeBSD-EN-16:04.hyperv,
FreeBSD-EN-16:05.hv_netvsc) with the Release Engineering team,
- so 10.1 and 10.2 users can easily get the fixes of KVP and TCP
- checksum by upgrading the system.</p>
+ so 10.1 and 10.2 users can easily get the fixes for KVP and TCP
+ checksums by upgrading the system.</p>
<p>We published BIS test cases for Hyper-V on github:
- https://github.com/FreeBSDonHyper-V/Test-BIS and we are going
- to publish the test cases for Azure soon.</p>
+ <a href="https://github.com/FreeBSDonHyper-V/Test-BIS">https://github.com/FreeBSDonHyper-V/Test-BIS</a>
+ and we are going to publish the test cases for Azure soon.</p>
</body>
<sponsor>Microsoft</sponsor>
@@ -1632,7 +1636,7 @@
testing.</p>
<p>With this change, randomization is applied to all non-fixed
- mappings. By randomization I mean the base address for the
+ mappings. By randomization, I mean that the base address for the
mapping is selected with a guaranteed amount of entropy
(bits). If the mapping was requested to be superpage aligned,
the randomization honors the superpage attributes.</p>
@@ -1641,18 +1645,18 @@
the allocator falls back to a first fit strategy if
fragmentation prevents entropy injection. It is trivial to
implement a strong mode where failure to guarantee the
- requested amount of entropy results in mapping request
- failure, but I do not consider that to be usable.</p>
+ requested amount of entropy results in failure of the mapping
+ request failure, but I do not consider that to be usable.</p>
<p>I have not fine-tuned the amount of entropy injected right
- now. It is only a quantitive change that will not change the
+ now, but that is only a quantitive change that will not change the
implementation. The current amount is controlled by
<tt>aslr_pages_rnd</tt>.</p>
<p>To not spoil coalescing optimizations, to reduce the page
- table fragmentation inherent to ASLR, and to keep the
- transient superpage promotion for the <tt>malloc</tt>ed
- memory, the locality is implemented for anonymous private
+ table fragmentation inherent to ASLR, and to retain
+ transient superpage promotion for <tt>malloc</tt>ed
+ memory, locality is implemented for anonymous private
mappings, which are automatically grouped until fragmentation
kicks in. The initial location for the anon group range is,
of course, randomized. After some additional tuning, the
@@ -1663,24 +1667,25 @@
<p>The default mode keeps the <tt>sbrk</tt> area unpopulated by
other mappings, but this can be turned off, which gives much
- more breathing bits on the small AS architectures (funny that
- 32 bits is considered small). This is tied with the question
+ more breathing room on the small address-space architectures
+ (it is funny that
+ 32 bits is now considered small). This is tied with the question
of following an application's hint about the <tt>mmap(2)</tt>
base address. Testing shows that ignoring the hint does not
- affect the function of common applications, but I would expect
+ affect the function of common applications, but I would expect that
more demanding code could break. By default <tt>sbrk</tt> is
preserved and <tt>mmap</tt> hints are satisfied, which can be
changed by using the <tt>kern.elf{32,64}.aslr_care_sbrk</tt>
- sysctl (currently enabled by default for wider testing).</p>
+ sysctls (currently enabled by default for wider testing).</p>
<p>Stack gap, W^X, shared page randomization, KASLR and other
- techniques are explicitly out of scope of this work.</p>
+ techniques are explicitly out of scope for this work.</p>
<p>The <tt>paxtest</tt> results for the run with the previous
version 5 of the patch applied and aggressively tuned can be
seen at
<a href="https://www.kib.kiev.ua/kib/aslr/paxtest.log"><tt>paxtest.log</tt></a>.
- For comparison, the run on Fedora 23 on the same machine is at
+ For comparison, a run on Fedora 23 on the same machine is at
<a href="https://www.kib.kiev.ua/kib/aslr/fedora.log"><tt>fedora.log</tt></a>.</p>
<p>ASLR is enabled on a per-ABI basis, and currently is only
@@ -1688,7 +1693,7 @@
ARMv6 ABIs. I expect to test and enable ASLR for arm64 as
well, later.</p>
- <p>The <tt>procctl(2)</tt> control for ASLR is implemented, but
+ <p>A <tt>procctl(2)</tt> control for ASLR is implemented, but
I have not provided a userspace wrapper around the syscall.
In fact, the most reasonable control needed is per-image and
not per-process, but we have no tradition to put the
@@ -1732,7 +1737,7 @@
This project 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, and
- adding a new throttling mechanism, to slow down offending
+ adding a new throttling mechanism to slow down offending
processes when a limit gets hit.</p>
<p>The code has been committed and will ship with &os;
@@ -1745,13 +1750,13 @@
</task>
<task>
- <p>Simplify locking, getting rid of rctl_lock altogether</p>
+ <p>Simplify locking, getting rid of <tt>rctl_lock</tt> altogether</p>
</task>
<task>
- <p>Improve statistics gathering by make it possible for
+ <p>Improve statistics gathering by making it possible for
<tt>rctl -u</tt> to retrieve usage counters at a fixed point
- of time</p>
+ in time</p>
</task>
<task>
@@ -1780,21 +1785,21 @@
</links>
<body>
- <p>Qt 5.6 is a great framework to build embedded GUI
+ <p>Qt 5.6 is a great framework for building embedded GUI
applications, so when Qt 5.6 was released it was natural to
- bring it up on Raspberry Pi. Current Qt support in ports is
- very Xorg-centric so as a proof of concept I created an
- experimental qt56-base and qt56-multimedia.</p>
-
- <p>qt56-base can be configured for a generic ARM device with the
- scfb video driver and specifically for Raspberry Pi in which
- case it supports eglfs mode with hardware OpenGL
+ bring it up on the Raspberry Pi. The current Qt support in ports is
+ very Xorg-centric, so as a proof of concept I created an
+ experimental <tt>qt56-base</tt> and <tt>qt56-multimedia</tt>.</p>
+
+ <p><tt>qt56-base</tt> can be configured for a generic ARM device with the
+ <tt>scfb</tt> video driver, and specifically for Raspberry Pi in which
+ case it supports EGLFS mode with hardware OpenGL
acceleration.</p>
</body>
<help>
<task>
- <p>Check how embedded use cases can be fit into current
+ <p>Check how embedded use cases can be fit into the current
<tt>bsd.qt.mk</tt> or whether a new port should be
introduced.</p>
</task>
@@ -1825,7 +1830,7 @@
and the kernel instantiates and attaches drivers according to
the information in the blob.</p>
- <p>This approach does not work when hardware is expandable. For
+ <p>This approach does not work when the hardware is expandable. For
example, the Raspberry Pi and Beaglebone Black have the
concept of capes or shields: snap-on PCBs that are connected
to IO headers on the main board and provide additional
@@ -1834,13 +1839,12 @@
trees can be overlaid on the base tree by the boot loader,
thus providing an accurate description to the kernel.</p>
- <p>The proposed patch add this functionality to ubldr. The user
- can specify a comma-separated list of overlays as U-Boot or
- the loader <tt>fdt_overlays</tt> variable and ubldr will load
+ <p>The proposed patch adds this functionality to <tt>ubldr</tt>. The user
+ can specify a comma-separated list of overlays to U-Boot or
+ the loader <tt>fdt_overlays</tt> variable and <tt>ubldr</tt> will load
them from the <tt>/boot/dtb/</tt> directory and do the
overlaying.</p>
</body>
-
</project>
<project cat='kern'>
@@ -1865,16 +1869,16 @@
<body>
<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
+ utilizing the well-tested CAM locking model and debugging
features. It will also be possible to process interrupts
generated by the inserted card, which is a prerequisite for
implementing the SDIO interface. SDIO support is necessary
- for communicating with WiFi/BT modules found on many
+ for communicating with the WiFi/BT modules found on many
development boards, like Wan Raspberry Pi 3.</p>
<p>Another feature that the new stack will have is support for
- sending SD commands from the userland applications using
- <tt>cam(3)</tt>. This will allow building device drivers in
+ sending SD commands from userland applications using
+ <tt>cam(3)</tt>. This will allow for building device drivers in
userland and make debugging much easier.</p>
<p>The first version of the code was uploaded to Phabricator for
@@ -2015,9 +2019,9 @@
<p><tt>lld</tt> currently lacks comprehensive linker script
expression evaluation support, and therefore cannot yet be
- used to link the FreeBSD kernel. It also lacks versioned
+ used to link the &os; kernel. It also lacks versioned
symbol support, and does not implement some options used in
- the FreeBSD boot loader components.</p>
+ the &os; boot loader components.</p>
<p>Ed has been running experimental world builds of
FreeBSD/amd64 with <tt>lld</tt> installed in place of
@@ -2043,7 +2047,7 @@
</task>
<task>
- <p>Add or improve support for remaining FreeBSD
+ <p>Add or improve support for the remaining &os;
architectures.</p>
</task>
@@ -2094,7 +2098,7 @@
<p>Object Storage</p>
<p>Ceph provides seamless access to objects using native
- language bindings or radosgw, a REST interface that is
+ language bindings or <tt>radosgw</tt>, a REST interface that is
compatible with applications written for S3 and Swift.</p>
</li>
@@ -2121,22 +2125,20 @@
nodes that are running ZFS. The end station would be running
<tt>bhyve</tt> on RBD disk that are stored in Ceph.</p>
- <p>The FreeBSD build will build most of the tools in Ceph. Note
- that the RBD-dependent items will not work since FreeBSD does
+ <p>The &os; build will build most of the tools in Ceph. Note
+ that the RBD-dependent items will not work since &os; does
not have RBD yet.</p>
- <p>Build Prerequisites</p>
-
<p>Compiling and building Ceph is tested on 11-CURRENT. It uses
- the CLANG toolset that is available, which needs to be at
+ the Clang toolset that is available, which needs to be at
least 3.7. Clang 3.4 (on 10.2-STABLE) does not have all the
required capabilities to compile everything.</p>
- <p>This setup will get things running for FreeBSD:</p>
+ <p>This setup will get things running for &os;:</p>
<ul>
<li>
- <p>Install bash and link it in <tt>/bin</tt> (requires root
+ <p>Install <tt>bash</tt> and link it in <tt>/bin</tt> (requires root
privileges):</p>
<p><tt>sudo pkg install bash</tt></p>
@@ -2157,7 +2159,7 @@
</li>
</ul>
- <p>Parts Not Yet Included</p>
+ <p>Parts Not Yet Included:</p>
<ul>
<li>
@@ -2174,9 +2176,9 @@
<li>
<p>BlueStore</p>
- <p>FreeBSD and Linux have a different AIO API, and that
+ <p>&os; and Linux have a different AIO API, and that
needs to be made compatible. Next to that is the
- discussion in FreeBSD about <tt>aio_cancel</tt> not
+ discussion in &os; about <tt>aio_cancel</tt> not
working for all device types.</p>
</li>
@@ -2191,22 +2193,22 @@
<p>Tests that verify the correct working of the above are also
excluded from the test set.</p>
- <p>Tests Not Yet Included</p>
+ <p>Tests Not Yet Included:</p>
<ul>
<li>
<p><tt>ceph-detect-init/run-tox.sh</tt></p>
<p>Because the current implementation does not know anything
- about FreeBSD rc-init.</p>
+ about &os;'s rc/init.</p>
</li>
<li>
- <p>Tests that make use of nosestests</p>
+ <p>Tests that make use of <tt>nosestests</tt></p>
<p>Calling these does not really work since
<tt>nosetests</tt> is not in <tt>/usr/bin</tt>, and
- calling through <tt>/usr/bin/env/nosetests</tt> does not
+ calling through <tt>/usr/bin/env nosetests</tt> does not
work on FreeBSD.</p>
</li>
@@ -2219,7 +2221,7 @@
</li>
</ul>
- <p>Things To Investigate</p>
+ <p>Things To Investigate:</p>
<ul>
<li>
@@ -2239,11 +2241,11 @@
<help>
<task>
- <p>Current and foremost task is to get the test set to
+ <p>The current and foremost task is to get the test set to
complete without errors. This includes fixing several
coredumps.</p>
- <p>Run integration tests to see if the FreeBSD daemons will
+ <p>Run integration tests to see if the &os; daemons will
work with a Linux Ceph platform.</p>
</task>
@@ -2257,11 +2259,11 @@
Device).</p>
<p>Investigate and see if an in-kernel RBD device could be
- developed a la <tt>ggate</tt>.</p>
+ developed akin to <tt>ggate</tt>.</p>
</task>
<task>
- <p>Integrate the FreeBSD <tt>/etc/rc.d</tt> init scripts in
+ <p>Integrate the &os; <tt>/etc/rc.d</tt> init scripts in
the Ceph stack for testing and running Ceph on production
machines.</p>
</task>
@@ -2288,15 +2290,15 @@
<body>
<p>The FreeBSD GNOME Team maintains the GNOME, MATE, and
CINNAMON desktop environments and graphical user interfaces for
- FreeBSD. GNOME 3 is part of the GNU Project. MATE is a fork of
+ &os;. GNOME 3 is part of the GNU Project. MATE is a fork of
the GNOME 2 desktop. CINNAMON is a desktop environment using
GNOME 3 technologies but with a GNOME 2 look and feel.</p>
- <p>This quarter, GNOME 3.18 and MATE 1.12 was committed to the
+ <p>This quarter, GNOME 3.18 and MATE 1.12 were committed to the
ports tree.</p>
- <p>The <tt>bsd.gnome.mk</tt> and <tt>bsd.mate.mk</tt> framework
- was replaced by the simpler <tt>Uses/gnome.mk</tt> and
+ <p>The <tt>bsd.gnome.mk</tt> and <tt>bsd.mate.mk</tt> frameworks
+ were replaced by the simpler <tt>Uses/gnome.mk</tt> and
<tt>Uses/mate.mk</tt> style.</p>
</body>
@@ -2353,14 +2355,14 @@
corporate donations and is used to fund and manage development
projects, conferences and developer summits, and provide
travel grants to FreeBSD developers. The Foundation purchases
- hardware to improve and maintain FreeBSD infrastructure and
- publishes FreeBSD white papers and marketing material to
+ hardware to improve and maintain &os; infrastructure and
+ publishes &os; white papers and marketing material to
promote, educate, and advocate for the FreeBSD Project. The
Foundation also represents the FreeBSD Project in executing
contracts, license agreements, and other legal arrangements
that require a recognized legal entity.</p>
- <p>Here are some highlights of what we did to help FreeBSD last
+ <p>Here are some highlights of what we did to help &os; last
quarter:</p>
<p>Fundraising Efforts</p>
@@ -2373,11 +2375,11 @@
<p>OS Improvements</p>
- <p>The Foundation improves FreeBSD by funding software
+ <p>The Foundation improves &os; by funding software
development projects approved through our proposal submission
- process and our three software developer staff members. Two
+ process, and our three software developer staff members. Two
Foundation-funded projects were started last quarter, the
- first to improve stability of the vnet network stack
+ first to improve the stability of the vnet network stack
virtualization infrastructure, and the second for phase two of
the FreeBSD/arm64 port project.</p>
@@ -2387,7 +2389,7 @@
bandwidth limits, porting <tt>libunwind</tt> to FreeBSD/arm,
bug fixes in the <tt>autofs</tt> automount daemon, an updated
version of the ELF Tool Chain, investigation of the
- <tt>lld</tt> linker, improved X86 hardware support, and VM
+ <tt>lld</tt> linker, improved x86 hardware support, and VM
subsystem stability improvements. Several of these projects
are described elsewhere in this quarterly report.</p>
@@ -2397,18 +2399,18 @@
on packaging the base system with <tt>pkg(8)</tt>, separating
debug files from the default base system so they can be
selected or deselected during an install, supporting
- preparations, testing for the on-time release of FreeBSD
+ preparations, testing for the on-time release of &os;
10.3, and producing 11-CURRENT and 10-STABLE snapshot
builds.</p>
- <p>FreeBSD Advocacy</p>
+ <p>&os; Advocacy</p>
<p>Anne Dickison, our Marketing Director, focused on creating
and updating marketing material to promote and teach people
- about FreeBSD.
+ about &os;.
<a href="https://www.freebsdfoundation.org/what-we-do/education-advocacy/">This material is available</a>
- for FreeBSD advocates to hand out at conferences and events to
- promote FreeBSD. She also worked on promoting FreeBSD work
+ for &os; advocates to hand out at conferences and events to
+ promote &os;. She also worked on promoting &os; work
being done over social media, blog posts, and articles.</p>
<p>Last quarter, we continued our Faces of FreeBSD series by
@@ -2416,23 +2418,24 @@
<a href="https://www.freebsdfoundation.org/blog/faces-of-freebsd-2016-scott-long/">Scott Long</a>
and
<a href="https://www.freebsdfoundation.org/blog/faces-of-freebsd-2016-sean-bruno/">Sean Bruno</a>.
- This is an opportunity to put a face to a name in the FreeBSD
+ This is an opportunity to put a face to a name in the &os;
community and get to know more about the people who
- contribute to FreeBSD.</p>
+ contribute to &os;.</p>
- <p>Work began on updating the FreeBSD 10.X brochure to
+ <p>Work began on updating the &os; 10.X brochure to
include the new 10.3 features.</p>
<p>We love getting stories from companies who are successfully
- using FreeBSD. Testimonials were received last quarter from
+ using &os;. Testimonials were received last quarter from
Chelsio and Acceleration Systems.</p>
<p>ZFS was making some headlines, so we wrote a blog entry on
- <a href="https://www.freebsdfoundation.org/blog/freebsd-and-zfs/">the longstanding relationship between FreeBSD and ZFS</a>.</p>
+ <a href="https://www.freebsdfoundation.org/blog/freebsd-and-zfs/">the
+ longstanding relationship between &os; and ZFS</a>.</p>
<p>We helped promote
- <a href="https://www.freebsdfoundation.org/blog/initial-freebsd-risc-v-architecture-port-committed/">the FreeBSD RISC-V</a>
- work being done.</p>
+ <a href="https://www.freebsdfoundation.org/blog/initial-freebsd-risc-v-architecture-port-committed/">the
+ &os; RISC-V</a> work being done.</p>
<p>Assistance was provided to Mellanox for their press release
highlighting
@@ -2446,22 +2449,22 @@
underrepresented groups. We provide financial support to the
*** DIFF OUTPUT TRUNCATED AT 1000 LINES ***
More information about the svn-doc-all
mailing list