Date: Mon, 28 Mar 2016 17:31:03 +0000 (UTC) From: Jason Helfman <jgh@FreeBSD.org> To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r48490 - head/en_US.ISO8859-1/articles/linux-emulation Message-ID: <201603281731.u2SHV3V1051986@repo.freebsd.org>
next in thread | raw e-mail | index | archive | help
Author: jgh Date: Mon Mar 28 17:31:03 2016 New Revision: 48490 URL: https://svnweb.freebsd.org/changeset/doc/48490 Log: - stick to American English spelling of behavior Modified: head/en_US.ISO8859-1/articles/linux-emulation/article.xml Modified: head/en_US.ISO8859-1/articles/linux-emulation/article.xml ============================================================================== --- head/en_US.ISO8859-1/articles/linux-emulation/article.xml Mon Mar 28 17:30:19 2016 (r48489) +++ head/en_US.ISO8859-1/articles/linux-emulation/article.xml Mon Mar 28 17:31:03 2016 (r48490) @@ -532,7 +532,7 @@ a new process in &linux; 2.6 happens using the <literal>clone</literal> syscall (fork variants are reimplemented using it). This clone syscall defines a set of flags that affect - behaviour of the cloning process regarding thread implementation. + behavior of the cloning process regarding thread implementation. The semantic is a bit fuzzy as there is no single flag telling the syscall to create a thread.</para> @@ -842,8 +842,8 @@ <para>&os; kernel has huge classes of locks. Every lock is defined by some peculiar properties, but probably the most important is the event linked to contesting holders (or in other terms, the - behaviour of threads unable to acquire the lock). &os;'s locking - scheme presents three different behaviours for contenders:</para> + behavior of threads unable to acquire the lock). &os;'s locking + scheme presents three different behaviors for contenders:</para> <orderedlist> <listitem> @@ -913,7 +913,7 @@ not about atomic operations or scheduling barriers, however).</para> - <para>This is a list of lock with their respective behaviours:</para> + <para>This is a list of lock with their respective behaviors:</para> <itemizedlist> <listitem> @@ -1080,7 +1080,7 @@ the starting point to the end point using lookup function, which is internal to VFS. The &man.namei.9; syscall can cope with symlinks, absolute and relative paths. When a path is looked up using - &man.namei.9; it is inputed to the name cache. This behaviour can + &man.namei.9; it is inputed to the name cache. This behavior can be suppressed. This routine is used all over the kernel and its performance is very critical.</para> </sect4> @@ -1472,7 +1472,7 @@ translate_traps(int signal, int trap_cod default (as of April 2007) and with all &linux; versions up to 2.6 it just determined what &man.uname.1; outputs. It is different with 2.6 emulation where setting this &man.sysctl.8; affects runtime - behaviour of the emulation layer. When set to 2.6.x it sets the + behavior of the emulation layer. When set to 2.6.x it sets the value of <literal>linux_use_linux26</literal> while setting to something else keeps it unset. This variable (plus per-prison variables of the very same kind) determines whether 2.6 @@ -2048,7 +2048,7 @@ pthread_mutex_unlock(&mutex);</progr <para>Waking up a thread sleeping on a futex is performed in the <function>futex_wake</function> function. First in this function - we mimic the strange &linux; behaviour, where it wakes up N threads + we mimic the strange &linux; behavior, where it wakes up N threads for all operations, the only exception is that the REQUEUE operations are performed on N+1 threads. But this usually does not make any difference as we are waking up all threads. Next in the @@ -2263,7 +2263,7 @@ openat(stdio, bah\, flags, mode) /* retu <package>www/linux-firefox</package>, <package>www/linux-opera</package>, <package>net-im/skype</package> and some games from - the Ports Collection. Some of the programs exhibit bad behaviour + the Ports Collection. Some of the programs exhibit bad behavior under 2.6 emulation but this is currently under investigation and hopefully will be fixed soon. The only big application that is known not to work is the &linux; &java; Development Kit and this is
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201603281731.u2SHV3V1051986>