system_call: New.

1 files changed, 14 insertions, 4 deletions

diff --git a/hurd/ng/trivialconfinementvsconstructorvsfork.mdwn b/hurd/ng/trivialconfinementvsconstructorvsfork.mdwn
index 4eeef6ee..0d91dee7 100644
--- a/hurd/ng/trivialconfinementvsconstructorvsfork.mdwn
+++ b/hurd/ng/trivialconfinementvsconstructorvsfork.mdwn
@@ -6,10 +6,11 @@ This comparison is about a simple situation: there is a parent process P, which
 
 # <a name="Trivial_Confinement"> Trivial Confinement </a>
 
-For trivial confinement, there is a system call to create a process from some memory pages. P performs the following steps:
+For trivial confinement, there is a [[system call]] to create a process from
+some memory pages. P performs the following steps:
 
 * Allocate some memory and put the code image of the child into that memory. This can be done by P, or for example by the file system which then gives the resulting memory (space bank) to P.
-* Perform the system call on that memory. The result is a capability to C.
+* Perform the [[system call]] on that memory. The result is a capability to C.
 * Send A to C using the returned capability.
 
 Note that it is up to the implementation of the system what happens with P's access to the memory which holds the child. For example, it is probably a good idea if it is at least unmapped, so it cannot accidentily write things in it. It could even be revoked, so that it can't write things in it, even if it wants to.
@@ -32,7 +33,16 @@ 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 calls, 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:
+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:
 
 * P calls fork(), creating P'.
 * P' drops B.
@@ -67,7 +77,7 @@ Except for the control, there is really only one other difference, and that's ad
 What it doesn't do is protect the code image against bugs in P. In the constructor the trusted and well-tested constructor code is handling the image, for trivial confinement the (very possibly) buggy program P. In particular, when starting a program from a file system, with trivial confinement the operation is:
 
 * Ask the file system for the code, receive a capability to a space bank with a copy (on write) of it.
-* Make the system call to turn it into a program.
+* Make the [[system call]] to turn it into a program.
 
 Now this isn't much more complicated than the constructor which does: