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

Contractions hunting.

Browse source
This commit is contained in:
Marc Fonvieille 2003-02-18 11:36:42 +00:00
parent 6cfcf45284
commit b0e0a590b4
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/head/; revision=16059
3 changed files with 29 additions and 29 deletions
en_US.ISO8859-1
articles
committers-guide
article.sgml
smp
article.sgml
books/arch-handbook/smp
chapter.sgml

26
en_US.ISO8859-1/articles/committers-guide/article.sgml
View file

@ -608,11 +608,11 @@
</itemizedlist>
<para>You will almost certainly get a conflict because
of the <literal>$Id: article.sgml,v 1.154 2003-02-08 23:43:56 will Exp $</literal> (or in FreeBSD's case,
of the <literal>$Id: article.sgml,v 1.155 2003-02-18 11:36:42 blackend Exp $</literal> (or in FreeBSD's case,
<literal>$<!-- stop expansion -->FreeBSD<!-- stop expansion -->$</literal>)
lines, so you will have to edit the file to resolve the conflict
(remove the marker lines and the second <literal>$Id: article.sgml,v 1.154 2003-02-08 23:43:56 will Exp $</literal> line,
leaving the original <literal>$Id: article.sgml,v 1.154 2003-02-08 23:43:56 will Exp $</literal> line intact).</para>
(remove the marker lines and the second <literal>$Id: article.sgml,v 1.155 2003-02-18 11:36:42 blackend Exp $</literal> line,
leaving the original <literal>$Id: article.sgml,v 1.155 2003-02-18 11:36:42 blackend Exp $</literal> line intact).</para>
</listitem>
<listitem>
@ -1036,9 +1036,9 @@ checkout -P</programlisting>
again until the matter is settled. Remember &ndash; with CVS we
can always change it back.</para>
<para>Don't impugn the intentions of someone you disagree with.
<para>Do not impugn the intentions of someone you disagree with.
If they see a different solution to a problem than you, or even
a different problem, it's not because they are stupid, because
a different problem, it is not because they are stupid, because
they have questionable parentage, or because they are trying to
destroy your hard work, personal image, or FreeBSD, but simply
because they have a different outlook on the world. Different
@ -1049,15 +1049,15 @@ checkout -P</programlisting>
seeing their solution, or even their vision of the problem,
with an open mind.</para>
<para>Accept correction. We're all fallible. When you've made
a mistake, apologize and get on with life. Don't beat up
yourself, and certainly don't beat up others for your mistake.
Don't waste time on embarassment or recrimination, just fix
<para>Accept correction. We are all fallible. When you have made
a mistake, apologize and get on with life. Do not beat up
yourself, and certainly do not beat up others for your mistake.
Do not waste time on embarassment or recrimination, just fix
the problem and move on.</para>
<para>Ask for help. Seek out (and give) peer reviews. One of
the ways open source software is supposed to excel is in the
number of eyeballs applied to it; this doesn't apply if nobody
number of eyeballs applied to it; this does not apply if nobody
will review code.</para>
</sect1>
@ -1218,7 +1218,7 @@ docs:Documentation Bug:nik:</programlisting>
authority over the architectural design and implementation
of the move to fine-grained kernel threading and locking.
He's also the editor of the SMPng Architecture Document.
If you're working on fine-grained SMP and locking, please
If you are working on fine-grained SMP and locking, please
coordinate with John. You can learn more about the
SMPng Project on its home page: <ulink
url="http://www.FreeBSD.org/smp/">
@ -2293,7 +2293,7 @@ docs:Documentation Bug:nik:</programlisting>
<step>
<para>Upgrade the copied port to the new version (remember
to change the <makevar>PORTNAME</makevar> so there
aren't duplicate ports with the same name).</para>
are not duplicate ports with the same name).</para>
</step>
<step>
@ -2552,7 +2552,7 @@ docs:Documentation Bug:nik:</programlisting>
<sect1 id="perks">
<title>Perks of the Job</title>
<para>Unfortunately, there aren't many perks involved with being a
<para>Unfortunately, there are not many perks involved with being a
committer. Recognition as a competent software engineer is probably
the only thing that will be of benefit in the long run. However,
there are at least some perks:</para>

16
en_US.ISO8859-1/articles/smp/article.sgml
View file

@ -78,7 +78,7 @@
<para>There are several existing treatments of memory barriers
and atomic instructions, so this section will not include a
lot of detail. To put it simply, one cannot go around reading
lot of detail. To put it simply, one can not go around reading
variables without a lock if a lock is used to protect writes
to that variable. This becomes obvious when you consider that
memory barriers simply determine relative order of memory
@ -164,7 +164,7 @@
<para>If you need a lock to check the state of a variable so
that you can take an action based on the state you read, you
can't just hold the lock while reading the variable and then
can not just hold the lock while reading the variable and then
drop the lock before you act on the value you read. Once you
drop the lock, the variable can change rendering your decision
invalid. Thus, you must hold the lock both while reading the
@ -224,7 +224,7 @@
context switch, the switch to the interrupt thread does not
switch vmspaces but borrows the vmspace of the interrupted
thread. In order to ensure that the vmspace of the
interrupted thread doesn't disappear out from under us, the
interrupted thread does not disappear out from under us, the
interrupted thread is not allowed to execute until the
interrupt thread is no longer borrowing its vmspace. This can
happen when the interrupt thread either blocks or finishes.
@ -308,7 +308,7 @@
for <function>critical_enter</function> to set a per-thread
flag that is cleared by its counterpart. If
<function>setrunqueue</function> is called with this flag
set, it doesn't preempt regardless of the priority of the new
set, it does not preempt regardless of the priority of the new
thread relative to the current thread. However, since
critical sections are used in spin mutexes to prevent
context switches and multiple spin mutexes can be acquired,
@ -415,7 +415,7 @@
stable.</para>
<para>Critical sections currently prevent migration since they
don't allow context switches. However, this may be too strong
do not allow context switches. However, this may be too strong
of a requirement to enforce in some cases since a critical
section also effectively blocks interrupt threads on the
current processor. As a result, it may be desirable to
@ -633,7 +633,7 @@
an exclusive (write) lock (&man.sx.xlock.9;). Internal functions
will not do locking at all. Externally visible ones will lock as
needed.
Those items that don't matter if the race is won or lost will
Those items that do not matter if the race is won or lost will
not be locked, since they tend to be read all over the place
(e.g. &man.device.get.softc.9;). There will be relatively few
changes to the newbus data structures, so a single lock should
@ -777,7 +777,7 @@
<title>Details of the Mutex Implementation</title>
<para>- Should we require mutexes to be owned for mtx_destroy()
since we can't safely assert that they are unowned by anyone
since we can not safely assert that they are unowned by anyone
else otherwise?</para>
<sect3>
@ -791,7 +791,7 @@
<para>- Describe the races with contested mutexes</para>
<para>- Why it's safe to read mtx_lock of a contested mutex
<para>- Why it is safe to read mtx_lock of a contested mutex
when holding sched_lock.</para>
<para>- Priority propagation</para>

16
en_US.ISO8859-1/books/arch-handbook/smp/chapter.sgml
View file

@ -78,7 +78,7 @@
<para>There are several existing treatments of memory barriers
and atomic instructions, so this section will not include a
lot of detail. To put it simply, one cannot go around reading
lot of detail. To put it simply, one can not go around reading
variables without a lock if a lock is used to protect writes
to that variable. This becomes obvious when you consider that
memory barriers simply determine relative order of memory
@ -164,7 +164,7 @@
<para>If you need a lock to check the state of a variable so
that you can take an action based on the state you read, you
can't just hold the lock while reading the variable and then
can not just hold the lock while reading the variable and then
drop the lock before you act on the value you read. Once you
drop the lock, the variable can change rendering your decision
invalid. Thus, you must hold the lock both while reading the
@ -224,7 +224,7 @@
context switch, the switch to the interrupt thread does not
switch vmspaces but borrows the vmspace of the interrupted
thread. In order to ensure that the vmspace of the
interrupted thread doesn't disappear out from under us, the
interrupted thread does not disappear out from under us, the
interrupted thread is not allowed to execute until the
interrupt thread is no longer borrowing its vmspace. This can
happen when the interrupt thread either blocks or finishes.
@ -308,7 +308,7 @@
for <function>critical_enter</function> to set a per-thread
flag that is cleared by its counterpart. If
<function>setrunqueue</function> is called with this flag
set, it doesn't preempt regardless of the priority of the new
set, it does not preempt regardless of the priority of the new
thread relative to the current thread. However, since
critical sections are used in spin mutexes to prevent
context switches and multiple spin mutexes can be acquired,
@ -415,7 +415,7 @@
stable.</para>
<para>Critical sections currently prevent migration since they
don't allow context switches. However, this may be too strong
do not allow context switches. However, this may be too strong
of a requirement to enforce in some cases since a critical
section also effectively blocks interrupt threads on the
current processor. As a result, it may be desirable to
@ -633,7 +633,7 @@
an exclusive (write) lock (&man.sx.xlock.9;). Internal functions
will not do locking at all. Externally visible ones will lock as
needed.
Those items that don't matter if the race is won or lost will
Those items that do not matter if the race is won or lost will
not be locked, since they tend to be read all over the place
(e.g. &man.device.get.softc.9;). There will be relatively few
changes to the newbus data structures, so a single lock should
@ -777,7 +777,7 @@
<title>Details of the Mutex Implementation</title>
<para>- Should we require mutexes to be owned for mtx_destroy()
since we can't safely assert that they are unowned by anyone
since we can not safely assert that they are unowned by anyone
else otherwise?</para>
<sect3>
@ -791,7 +791,7 @@
<para>- Describe the races with contested mutexes</para>
<para>- Why it's safe to read mtx_lock of a contested mutex
<para>- Why it is safe to read mtx_lock of a contested mutex
when holding sched_lock.</para>
<para>- Priority propagation</para>