os/doc
3
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

Grammar and spelling changes, comma and semicolon reductions, run-on

Browse source 
sentences debigulated, Britishisms Muricanized.
This commit is contained in:
Warren Block 2016-10-28 18:10:40 +00:00
parent 63717ecb81
commit 452efcf004
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/head/; revision=49603
1 changed files with 96 additions and 96 deletions
Download patch file Download diff file Expand all files Collapse all files

192
en_US.ISO8859-1/htdocs/news/status/report-2016-07-2016-09.xml
View file

@ -110,10 +110,10 @@
<p>Currently, &os; is well proven as a base for routers
(<strong>pfSense</strong>, <strong>OPNSense</strong>,
<strong>BSDRP</strong>) and NAS (<strong>FreeNAS</strong>,
<strong>zfsGuru</strong>, <strong>Nas4Free</strong>). However,
<strong>zfsGuru</strong>, <strong>NAS4Free</strong>). However,
&os;-based solutions are almost completely absent in the
virtualization area, and <strong>ClonOS</strong> is one of the
attempts to change it.
attempts to change that.
</p>
<p>ClonOS is a new free open-source &os;-based platform for virtual
@ -138,7 +138,7 @@
management)</li>
<li>additional features such as go-micro services (obtaining
VMs, resizing disks and so on)</li>
VMs, resizing disks, and so on)</li>
</ul>
</body>
@ -147,7 +147,7 @@
regard we are interested in finding more people and companies who
used &os; in hosting tasks. In addition, it could be great to
work with the developers of existing NAS solutions (zfsGuru,
Nas4Free)
NAS4Free).
</task>
</help>
</project>
@ -358,7 +358,7 @@
</project>
<project cat='gsoc'>
<title>ptnet Driver and bhyve Device Model</title>
<title><tt>ptnet</tt> Driver and <tt>bhyve</tt> Device Model</title>
<contact>
<person>
@ -491,7 +491,7 @@
lightweight, while still being visually appealing and easy to
use.</p>
<p>During this quarter, the team has kept the following applications
<p>During this quarter, the team has kept these applications
up-to-date:</p>
<ul>
@ -584,10 +584,10 @@
<p>This project was started during Google Summer of Code this year.
The aim was to create a library which can convert the audit trail
files in Linux Audit format or the format used by Windows to the BSM
format (the format &os; uses for its audit logs). Apart from that,
format used by &os; for its audit logs. Apart from that,
I wanted to create a simple command-line tool and extend
<tt>auditdistd</tt> so that it is possible to send non-BSM logs to
<tt>auditdistd</tt> over a secure connection and save those audit
it over a secure connection and save those audit
logs on disk, preferably in the BSM format.</p>
<p>So far, it is possible to reasonably convert some of the most
@ -597,8 +597,8 @@
command-line tool is usable but not perfect.</p>
<p>The present work focuses on configuring the secure TLS connection
between CentOS and <tt>auditdistd</tt>. I've already tried using
rsyslogd but wasn't able to make it work.</p>
between CentOS and <tt>auditdistd</tt>. I have already tried using
rsyslogd but was not able to make it work.</p>
</body>
<sponsor>
@ -613,7 +613,7 @@
<task>Configure <tt>auditdistd</tt> to be able to communicate with some
software on CentOS over TLS in order to receive audit logs. I
wasn't able to come up with a simple solution for that.</task>
was not able to come up with a simple solution for that.</task>
<task>Additional open tasks are listed on the Wiki page and in the
TODO file in the root directory of the project.</task>
@ -635,7 +635,7 @@
<body>
<p>Non-Transparent Bridges allow creation of memory windows between
different systems, using the regular PCIe links of CPUs as a
different systems using the regular PCIe links of CPUs as a
transport. During the last quarter, the NTB subsystem gained a
significant set of improvements and fixes:</p>
@ -752,7 +752,7 @@
has been tested and improved in order to gain production quality.
Most of this effort has been invested in development and
benchmarking of the on-chip Gigabit Ethernet (NETA) functionality.
Numerous bug fixes, as well as some new features, have been
Numerous bug fixes and some new features have been
introduced.</p>
<p>Work completed this quarter includes:</p>
@ -963,7 +963,7 @@
fixes or functionality in the trees of NetBSD, &os;, OpenBSD, and
DragonFly BSD.</p>
<p>One thing which became obvious very quickly, was the
<p>One thing which became obvious very quickly was the
inconsistency between operating systems about where and/or which
version a utility originated in, despite our common heritage.</p>
@ -971,9 +971,9 @@
details in pages which already had a history section and making
patches for those which did not.</p>
<p>From there, changes were propogated out to NetBSD, OpenBSD and
<p>From there, changes were propogated out to NetBSD, OpenBSD, and
Dragonfly BSD where applicable (not all utilities originated from
the same source or implimentation, for example).</p>
the same source or implementation, for example).</p>
<p>This was a good exercise in:</p>
@ -986,7 +986,7 @@
<li>Becoming familiar with the locations where things are
documented and with external sources of historical information,
such as the BSD Family Tree which is included in the &os; base
such as the BSD Family Tree included in the &os; base
system, and projects like <a href="http://www.tuhs.org">The UNIX
Heritage Society</a> and the <a href="http://man.cat-v.org">manual
library</a> on <a href="http://cat-v.org">cat-v.org</a> which
@ -999,10 +999,10 @@
<help>
<task>Cover the remaining manuals for userland utilities, and maybe
expand onto library and syscall APIs, though I say that without
estimating the feasibility &mdash; components originating from a
closed-source operating system are tricky to document the history
of, since older versions are not always available.</task>
expand into library and syscall APIs, though I say that without
estimating the feasibility. The history of components originating from a
closed-source operating system is tricky to document,
since older versions are not always available.</task>
</help>
</project>
@ -1032,8 +1032,8 @@
</links>
<body>
<p>&os; provides an API for guest OSes to access shared folders on
the host OS so that the kernel driver can expose them to the
<p>&os; provides an API for guest operating systems to access shared folders on
the host so that the kernel driver can expose them to the
guest's userland. This project aims to add such functionality to
the VirtualBox Guest Additions driver.</p>
@ -1046,14 +1046,14 @@
<help>
<task>Finish the missing pieces.</task>
<task>implement proper locking.</task>
<task>Implement proper locking.</task>
<task>general clean-up and bugfixes.</task>
<task>General clean-up and bugfixes.</task>
</help>
</project>
<project cat='kern'>
<title>evdev Support</title>
<title><tt>evdev</tt> Support</title>
<contact>
<person>
@ -1081,7 +1081,7 @@
<body>
<p><tt>evdev</tt> is a portable, API-compatible implementation of
the Linux <tt>/dev/input/eventX</tt> interface. It covers a wide
variaty of input devices like keyboards, mice, and touchscreens
variety of input devices like keyboards, mice, and touchscreens
(with multitouch support), and support for it is implemented in a
lot of existing userland components like Qt, <tt>libinput</tt>, and
<tt>tslib</tt>.</p>
@ -1093,7 +1093,7 @@
also added for TI's AM33xx touchstreen controller (the popular
BeagleBone is based on the AM33xx) and the official touschreen for
the Raspberry Pi. Multitouch support for the Raspberry Pi was
successfully demoed using the lastest Qt development branch.</p>
successfully demonstarted using the latest Qt development branch.</p>
</body>
<help>
@ -1134,11 +1134,11 @@
</links>
<body>
<p>Transparent superpage support has been added. This will allow
<p>Transparent superpage support has been added. This allows
&os; to create 2MiB blocks with a single pagetable and TLB entry.
This has shown a small but significant improvement in the
This shows a small but significant improvement in the
buildworld time on ThunderX machines. Superpages have been
enabled in head with and merged to stable/11, but they are
enabled in head and merged to stable/11, but they are
disabled by default on stable/11 due to a lack of testing
there.</p>
@ -1230,12 +1230,12 @@
leveldb.</li>
</ul>
<p>In our development repository, we have done the following
<p>In our development repository, we have done this
work:</p>
<ul>
<li>The plasma5 branch has been kept up to date with KDE's upstream and
contains ports for Frameworks 5.26.0, Plasma Desktop 5.8.0 and
contains ports for Frameworks 5.26.0, Plasma Desktop 5.8.0, and
Applications 16.08.1 (branches/plasma5).</li>
</ul>
@ -1256,14 +1256,14 @@
<p>The third quarter started with the handover to the ninth Core
team as it took office. With four members returning from the
previous core (Baptiste Daroussin, Ed Maste, George Neville-Neil
and Hiroki Sato); one returning member after a term away (John
Baldwin) and four members new to core (Allan Jude, Kris Moore,
Benedict Reuschling and Benno Rice) the new core team represents
and Hiroki Sato), one returning member after a term away (John
Baldwin), and four members new to core (Allan Jude, Kris Moore,
Benedict Reuschling and Benno Rice), the new core team represents
just about the ideal balance between experience and fresh
blood.</p>
<p>Beyond handing over all of the ongoing business, reviewing
everything on Core's agenda and other routine changeover
everything on Core's agenda, and other routine changeover
activities, the first action of the new core was to respond to a
query from Craig Rodrigues concerning how hardware supplied to the
project through donations to the &os; Foundation was being
@ -1272,7 +1272,7 @@
<p>The Foundation does keep records of what hardware has been
supplied over time and has some idea of the original purpose that
hardware was provisioned for, but does not track the current usage
of the project's hardware assets. Cluster administration keep
of the project's hardware assets. Cluster administration keeps
their own configuration database, but this is not suitable for
general publication and covers much more than Foundation supplied
equipment. After some discussion it was decided that updated
@ -1327,7 +1327,7 @@
published. Early access to information about vulnerabilities is
contingent on their ability to avoid premature disclosure, and
without such, they could not have security advisories and
patches ready to go immediately the vulnerability is
patches ready to go immediately when the vulnerability is
published.</p>
<p>However, in this case, vulnerabilities were already public and
@ -1343,8 +1343,8 @@
<p>The OpenSSH project has deprecated DSA keys upstream. &os; had
kept DSA keys enabled in the later 10.x releases for compatibility
reasons, but with the release of 11.0 the time has come to
synchronise again with upstream. Since there are numerous DSA
keys in use in the &os; cluster this has necessitated an
synchronize again with upstream. Since there are numerous DSA
keys in use in the &os; cluster, this necessitated an
exercise to get replacement keys installed. Core would like to
thank David Wolfskill and the accounts team for handling the surge
in key changes with a great deal of aplomb.</p>
@ -1376,41 +1376,41 @@
existing code correctly interoperated with readers, both kernel-
and user-space, giving them lock-less access to the actual data
('timehands') needed to derive the time of day from the
timecounter hardware, in the presence of updaters. But updates
timecounter hardware in the presence of updaters. But updates
of the timehands, which are performed by periodic clock
interrupts, the ntpd-driven sys_ntp_adjtime(2) syscall, the
settimeofday(2) syscall, pps sync, and possibly other sources,
interrupts, the ntpd-driven <tt>sys_ntp_adjtime(2)</tt> syscall, the
<tt>settimeofday(2)</tt> syscall, pps sync, and possibly other sources,
were not coordinated. Moreso, the NTP code was locked by Giant,
which did not really serve any purpose.</p>
<p>As result of the work, locking was applied to ensure that any
timehands adjustments are performed by single mutator. An
<p>As a result of the work, locking was applied to ensure that any
timehands adjustments are performed by a single mutator. An
interesting case is the parallel modification of the timehands
from the top of the kernel, for instance the settimeoday(2)
from the top of the kernel, for instance the <tt>settimeoday(2)</tt>
syscall, and a simultaneous clock tick event, where the syscall
has already acquired the resources. In this case, it is highly
desirable to not block (spin) in the tick handler, and the
required adjustments are performed by the already executing call
from top half. There, the typical trylock operation is desired,
which was surprisingly lacking from our spinlock implementation.
mtx_trylock_spin(9) was implemented and is used for this
from the top half. There, the typical trylock operation is desired,
which was surprisingly lacking in our spinlock implementation.
<tt>mtx_trylock_spin(9)</tt> was implemented and is used for this
purpose.</p>
<p>The userspace getttimeofday(2) implementation was enhanced to
<p>The userspace <tt>getttimeofday(2)</tt> implementation was enhanced to
allow syscall-less operation on machines that use HPET hardwire
for timecounters. The HPET algorithm coexists with older
RDTSC-based code, allowing dynamic switching of timecounters.
HPET registers a page that is mmap(2)-ed readonly by libc into
HPET registers a page that is <tt>mmap(2)</tt>-ed readonly by libc into
userland application programs' address space as needed.
Measurements demonstrated modest improvements in gettimeofday(2)
performance, but not unexpectedly even the syscall-less HPET
Measurements demonstrated modest improvements in <tt>gettimeofday(2)</tt>
performance, but, not unexpectedly, even the syscall-less HPET
timecounter is slower than invoking a syscall for RDTSC.</p>
<p>Some not strictly interwined but related code is the
time-bound sleep implementation. Handling of races between
callouts and the top-half code that sets and processes the
timeouts depended on the many fine details of the
callout_stop(9) KPI (kernel programming interface). In
<tt>callout_stop(9)</tt> KPI (kernel programming interface). In
particular, races or unpunctual KPI changes usually result in
the &quot;catch-all&quot; unkillable thread state with the
&quot;-&quot; waitchain bug. The sleepqueue timeout code was
@ -1440,10 +1440,10 @@
<body>
<p>UEFI (Unified Extensible Firmware Interface) specifies two
kinds of services for use by operating systems. Boot Services are
designed for OS loaders to be able to load and initialize kernels,
while Runtime Services are supposed to be used by the kernels
designed for OS loaders to load and initialize kernels,
while Runtime Services are meant to be used by kernels
during regular system operations. The boot and runtime phases are
explicitely separated. During boot, when loaders are executed,
explicitly separated. During boot, when loaders are executed,
the machine configuration is owned by UEFI. During runtime, the
kernel manages the configuration, but needs to inform the firmware
about any changes that are made.</p>
@ -1453,7 +1453,7 @@
&os; codebase. For instance, the firmware notification of the
future runtime configuration must be done while the loader is
effectively still in control. In technical terms, the
SetVirtualAddressMap() call must be made with the 1:1
<tt>SetVirtualAddressMap()</tt> call must be made with the 1:1
physical:virtual mapping on amd64 systems, which for &os; means
that the call can be only issued by the loader. But the loader
needs to know intimate details of the kernel address map to
@ -1474,31 +1474,31 @@
centered around utilizing the direct address map (DMAP) on
amd64, which currently always exists and linearly maps at
least the lower 4G of physical addresses at some KVA location.
It was supposed that kernel would export the DMAP details like
It was supposed that the kernel would export the DMAP details like
linear base and guaranteed size for loader from its ELF image,
and provide the needed overflow map if the DMAP cannot
completely serve. Unfortunately, two show-stopper bugs were
discovered with this approach.</p>
<p>First, EDK-based firmwares apparently require that the
<p>First, EDK-based firmware apparently requires that the
runtime mapping exists simultaneously with the physical
mapping for the SetVirtualAddressMap() call. Second, there
mapping for the <tt>SetVirtualAddressMap()</tt> call. Second, there
were references from other open-source projects mentioning
that some firmwares required the presence of the physical
mapping during runtime call. Effectively, this forces both
that some firmware required the presence of the physical
mapping during the runtime call. Effectively, this forces both
kernel and loader to provide both mappings for all runtime
calls.</p>
<p>With such restrictions, informing the firmware about the
details of the kernel address space only adds useless work.
We could just as easily establish the 1:1 physical mapping
during runtime and get rid of SetVirtualAddressMap() entirely.
during runtime and get rid of <tt>SetVirtualAddressMap()</tt> entirely.
This approach was coded and the kernel interface to access
runtime services is based on it.</p>
<p>During the development, in particular, when trying to make
<p>During the development, particularly when trying to make
the loader modifications, it was quickly realized that there
were no fault-reporting facilities in loader.efi. Machine
were no fault-reporting facilities in <tt>loader.efi</tt>. Machine
exceptions resulted in a silent hang. Curiosly, in such a
situation the Intel firmware outputs the error code over the
serial port on 115200/8/1 settings, regardless of UEFI console
@ -1506,11 +1506,11 @@
Unfortunately, the error code alone is not enough to diagnose
most problems.</p>
<p>A primitive fault reporter was written for loader.efi on
<p>A primitive fault reporter was written for <tt>loader.efi</tt> on
amd64, which intercepts exceptions from the firmware IDT and
dumps the machine state to the loader console. Due to
dumps the machine state to the loader console. Due to the
complexity of the interception and possible bugs which might
do more harm than good there, the dumper is only activated by
do more harm than good there, the dumper is only activated with
explicit administrator action.</p>
<p>Note that the described work only provides the kernel
@ -1546,9 +1546,9 @@
respective branches, among other things.</p>
<p>The &os; Release Engineering Team continued the 11.0-RELEASE
cycle which was planned to be released in September, but as
result of several last-minute issues that needed to be
addressed, the final release announcement was delayed.</p>
cycle which was planned to be released in September, but as a
result of several last-minute issues,
the final release announcement was delayed.</p>
</body>
<sponsor>
@ -1595,31 +1595,31 @@
<body>
<p>We are sad to report that both GSoc projects failed. The
<tt>libdevq</tt> project was abandonned as the student
<tt>libdevq</tt> project was abandoned as the student
disappeared. The kernel project was incomplete because the
student could not work for personal reasons. He plans to
resume work and complete the task, even though GSoC 2016 is
finished.</p>
<p>The X.org server version 1.18.4 together with updates for
<p>X.org server version 1.18.4 and updates for
the <tt>xf86-video-ati</tt> and <tt>xf86-video-intel</tt> DDX
drivers are ready for wider testing and a CFT will be sent out
shortly. These updates are required in order to use newer DRM
drivers are ready for wider testing. A CFT will be sent out
shortly. These updates are required to use newer DRM
versions.</p>
<p>The missing functionality from <tt>libdrm</tt> that is
needed by the <tt>amdgpu</tt> driver has been added. These
chances will be committed to the ports tree shortly after the
changes will be committed to the ports tree shortly after the
xorg-server update.</p>
<p>DRM from Linux 4.8 was ported to the <tt>drm-next</tt>
branch. This branch should be used for <tt>radeon</tt> and
<tt>amdgpu</tt> cards; for <tt>i915</tt> cards the
<tt>drm-next-4.7</tt> should be used, due to instabilities in
the intel driver in <tt>drm-next</tt> branch.</p>
<tt>amdgpu</tt> cards. The <tt>drm-next-4.7</tt> branch should be used
for <tt>i915</tt> cards due to instabilities in
the <tt>intel</tt> driver in <tt>drm-next</tt> branch.</p>
<p>Johannes Lundberg has been working on getting the Wayland
enviroment up and running on &os;. The Wayland ports are in
environment running on &os;. The Wayland ports are in
a working state except for the Weston compositor.</p>
<p>The current Weston port (from DragonFlyBSD) might be
@ -1675,7 +1675,7 @@
<p>Our work is 100% funded by your donations. Our spending
budget for 2016 is $1,250,000 and we have raised $271,500 so
far. Our Q1-Q3 financial reports will be posted in early
November. As you can see, we need your donations in order to
November. As you can see, we need your donations to
continue supporting &os; at our current level. Please consider
making a donation at <a
href="https://www.FreeBSDfoundation.org/donate/">https://www.FreeBSDfoundation.org/donate/</a>.</p>
@ -1685,22 +1685,22 @@
<p>The Foundation improves &os; by funding software development
projects approved through our proposal submission process, and
our internal software developer staff members. Two
Foundation-funded projects continued last quarter; one project
Foundation-funded projects continued last quarter: one project
is to port NetBSD's <tt>blacklistd</tt> daemon and related
elements to &os;, and the second is phase two of the &os;/arm64
port.</p>
<p>Foundation staff members were responsible for many changes
over the quarter. Kostik Belousov accomplished the following
over the quarter. Kostik Belousov accomplished this
work last quarter:</p>
<ul>
<li>Provided kernel support for EFI Runtime Services calls.</li>
<li>Implemented getttimeofday(2) purely in userspace for HPET
<li>Implemented <tt>getttimeofday(2)</tt> purely in userspace for HPET
timers</li>
<li>Implemented fdatasync(2)</li>
<li>Implemented <tt>fdatasync(2)</tt></li>
<li>Improved the locking of the time keeping code</li>
@ -1712,8 +1712,8 @@
<li>Improved the process management and ptrace code</li>
</ul>
<p>Ed Maste, our Project Development Director, accomplished the
following work last quarter:</p>
<p>Ed Maste, our Project Development Director, accomplished this
work last quarter:</p>
<ul>
<li>Worked on &os;/arm64 issues and Cavium ThunderX
@ -1725,7 +1725,7 @@
<li>Switched to using LLVM's <tt>libunwind</tt> in the base system</li>
<li>Improved the reproducibility of builds in &os; base system
<li>Improved the reproducibility of builds in the &os; base system
and ports</li>
<li>Reviewed the <tt>blacklistd</tt> work that is in
@ -1794,9 +1794,9 @@
<p>A large part of our efforts are dedicated to advocating for
the Project. This includes promoting work being done by others
using &os;; producing advocacy literature to teach people about
&os; and easing the path to starting out with &os; and contributing
to the Project; and attending and getting other &os;
using &os;, producing advocacy literature to teach people about
&os; and ease the path to starting out with &os;, contributing
to the Project, and attending and getting other &os;
contributors to volunteer to run &os; events, staff &os; tables,
and give &os; presentations.</p>
@ -1910,7 +1910,7 @@
<p>Other Stuff We Did</p>
<p>We welcomed Kylie Liange and Philip Paeps to the Board of
<p>We welcomed Kylie Liang and Philip Paeps to the Board of
Directors. More information and interviews can be found at: <a
href="https://www.FreeBSDfoundation.org/blog/FreeBSD-foundation-welcomes-new-board-members/">https://www.FreeBSDfoundation.org/blog/FreeBSD-foundation-welcomes-new-board-members/</a>.</p>
@ -2119,13 +2119,13 @@
<p>The upstream <tt>lld</tt> project has now implemented
nearly all of the functionality required to link the amd64
FreeBSD base system, including the kernel. The boot loader
&os; base system, including the kernel. The boot loader
components and <tt>rescue</tt> utilities currently do not
build with <tt>lld</tt>.</p>
</body>
<help>
<task>Merge <tt>lld</tt> to FreeBSD head as part of the Clang
<task>Merge <tt>lld</tt> to &os; head as part of the Clang
3.9.0 import.</task>
<task>Request a ports exp-run with <tt>lld</tt> installed as