Been reading another LWN issue...

3 files changed, 27 insertions, 16 deletions

diff --git a/hurd/glibc/hurd-specific_api.mdwn b/hurd/glibc/hurd-specific_api.mdwn
index 75220279..7ead63cd 100644
--- a/hurd/glibc/hurd-specific_api.mdwn
+++ b/hurd/glibc/hurd-specific_api.mdwn
@@ -82,7 +82,13 @@ programs -- they are used to produce `.h` files.
   <dt><tt><b>openport</b> (io_t port, int flags);</tt></dt>
   <p>
   </p>
-  <dd>Open a file descriptor on a port. FLAGS are as for <tt>open</tt>; flags affected by <tt>io_set_openmodes</tt> are not changed by this. If successful, this consumes a user reference for PORT (which will be deallocated on close.) See <tt>&amp;lt;hurd/io.defs&amp;gt;</tt> and <tt>&amp;lt;hurd/io.h&amp;gt;</tt>.</dd>
+  <dd>Open a [[unix/file_descriptor]] on a [[microkernel/mach/port]].  FLAGS
+    are as for <tt>open</tt>; flags affected by <tt>io_set_openmodes</tt> are
+    not changed by this.  If successful, this consumes a user reference for
+    PORT (which will be deallocated on close.) See
+    <tt>&amp;lt;hurd/io.defs&amp;gt;</tt> and
+    <tt>&amp;lt;hurd/io.h&amp;gt;</tt>.
+  </dd>
   <p>
   </p>
   <dt><tt>task_t</tt></dt>
diff --git a/hurd/ng/trivialconfinementvsconstructorvsfork.mdwn b/hurd/ng/trivialconfinementvsconstructorvsfork.mdwn
index 0d91dee7..949895e7 100644
--- a/hurd/ng/trivialconfinementvsconstructorvsfork.mdwn
+++ b/hurd/ng/trivialconfinementvsconstructorvsfork.mdwn
@@ -34,15 +34,15 @@ This mechanism is targeted at a specific use pattern, namely that a process is c
 # <a name="POSIX_Fork"> </a> POSIX Fork
 
 POSIX fork, or rather fork+exec, is how things are done on many current
-systems. It may be insightful to see it included in the comparison, especially
-for people who are new to the subject. There are two [[system call]]s, fork and
-exec. Fork will create a clone of the current process, including all the
-capabilities (that is, file descriptors) of the parent (except the ones which
-have explicitly been excluded). Exec is a [[system call]] which really goes to
-the filesystem, not the kernel (although on systems which use it, the
-filesystem usually resides in the kernel), and asks it to spawn a new process
-from the contents of a certain path in place of the caller. This passes all
-capabilities to the new process. The procedure is:
+systems.  It may be insightful to see it included in the comparison, especially
+for people who are new to the subject.  There are two [[system call]]s, fork
+and exec.  Fork will create a clone of the current process, including all the
+capabilities (that is, [[unix/file_descriptor]]s) of the parent (except the
+ones which have explicitly been excluded).  Exec is a [[system call]] which
+really goes to the filesystem, not the kernel (although on systems which use
+it, the filesystem usually resides in the kernel), and asks it to spawn a new
+process from the contents of a certain path in place of the caller.  This
+passes all capabilities to the new process.  The procedure is:
 
 * P calls fork(), creating P'.
 * P' drops B.
@@ -62,7 +62,11 @@ In contrast, the other two options don't pass anything by default. If there is a
 
 The problem of fork+exec can be solved. It is if the default would be to not pass capabilities to the new process, but specify a list of capabilities that it should keep, or (like in the other cases) pass them over a new channel which is implicitly created during the fork. However, in that case the only difference with trivial confinement is that P' dies in the process (and thus must be created to prevent P from dying). Almost any use of exec is in practice preceded by a fork for this purpose. It would be easier to make trivial confinement the default operation and let P die directly after it in the rare case that it should.
 
-The only reason for continuing to use fork+exec would be that it is what existing programs do. However, they break anyway if they need to specify which file descriptors to pass. So they need to be adapted. Therefore, it's better to make the usual spawning method the primitive one, and emulate the other.
+The only reason for continuing to use fork+exec would be that it is what
+existing programs do.  However, they break anyway if they need to specify which
+[[unix/file_descriptor]]s to pass.  So they need to be adapted. Therefore, it's
+better to make the usual spawning method the primitive one, and emulate the
+other.
 
 # <a name="Trivial_Confinement_vs_Construct"> Trivial Confinement vs Constructor </a>
 
diff --git a/hurd/translator/magic.mdwn b/hurd/translator/magic.mdwn
index 06ee798b..84bacdfb 100644
--- a/hurd/translator/magic.mdwn
+++ b/hurd/translator/magic.mdwn
@@ -1,20 +1,21 @@
-[[!meta copyright="Copyright © 2006, 2007, 2008 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2006, 2007, 2008, 2010 Free Software Foundation,
+Inc."]]
 
 [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
 id="license" text="Permission is granted to copy, distribute and/or modify this
 document under the terms of the GNU Free Documentation License, Version 1.2 or
 any later version published by the Free Software Foundation; with no Invariant
 Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
-is included in the section entitled
-[[GNU Free Documentation License|/fdl]]."]]"""]]
+is included in the section entitled [[GNU Free Documentation
+License|/fdl]]."]]"""]]
 
 The magic translator provides `/dev/fd`.
 
     $ showtrans /dev/fd
     /hurd/magic --directory fd
 
-The `/dev/fd` directory holds the open file descriptors for your current
-process.  You can't see them with `ls -l /dev/fd/` but you can see them
+The `/dev/fd` directory holds the open [[unix/file_descriptor]]s for your
+current process.  You can't see them with `ls -l /dev/fd/` but you can see them
 individually like this:
 
     $ ls -l /dev/fd/0