system_call: New.

5 files changed, 40 insertions, 16 deletions

diff --git a/hurd/glibc/hurd-specific_api.mdwn b/hurd/glibc/hurd-specific_api.mdwn
index aeb63d91..75220279 100644
--- a/hurd/glibc/hurd-specific_api.mdwn
+++ b/hurd/glibc/hurd-specific_api.mdwn
@@ -1,17 +1,18 @@
-[[!meta copyright="Copyright © 2002, 2007, 2008 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2002, 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]]."]]"""]]
 
 [[!meta title="Hurd-specific glibc API"]]
 
 These functions have meaning only under Hurd.  They are needed to get port
-names that are used in native Hurd API (the RPC calls to servers).  The `.defs`
+names that are used in native Hurd API (the [[RPC]]s to servers).  The `.defs`
 and `.h` files can be found in `/include/hurd` when all development files are
 installed (Debian package `hurd-dev`.)  Note that `.defs` are not included in C
 programs -- they are used to produce `.h` files.
@@ -157,7 +158,7 @@ programs -- they are used to produce `.h` files.
   </p>
   <dt><tt>thread_t</tt></dt>
   <dt><tt><b>hurd_thread_self</b> (void);</tt></dt>
-  <dd>Return the current thread's thread port. This is a cheap operation (no system call), but it relies on Hurd signal state being set up.</dd>
+  <dd>Return the current thread's thread port. This is a cheap operation (no [[system call]]), but it relies on Hurd signal state being set up.</dd>
   <p>
   </p>
   <dt><tt>error_t</tt></dt>
diff --git a/hurd/networking.mdwn b/hurd/networking.mdwn
index ff16eb25..bdf9def2 100644
--- a/hurd/networking.mdwn
+++ b/hurd/networking.mdwn
@@ -1,12 +1,13 @@
-[[!meta copyright="Copyright © 2000, 2008 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2000, 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]]."]]"""]]
 
 For each supported `PF_*` protocol family, there is a file `/servers/socket/N`
 where `N` is the numberic value fo the `PF_*` symbol.  Right now
@@ -17,10 +18,10 @@ where `N` is the numberic value fo the `PF_*` symbol.  Right now
 User programs open those files, and use the `socket_create` [[RPC]] to make a
 new socket.  With that socket, they can use the other `socket_*` RPCs and also
 the `io_*` RPCs.  The `socket_*` RPCs are essentially clones of the [[Unix]]
-syscalls in question.
+[[system call]]s in question.
 
 The only exception is `sockaddrs`, which are implemented as [[ports|libports]]
-instead of the opaque data arrays they are in the syscalls.  You manipulate
+instead of the opaque data arrays they are in the system calls.  You manipulate
 `sockaddr` ports with the `socket_create_address`, `socket_fabricate_address`,
 and `socket_whatis_address` calls.  The `sockaddr` port is then used in socket
 calls like `socket_connect` and `socket_accept`.
diff --git a/hurd/ng/microkernelcoyotos.mdwn b/hurd/ng/microkernelcoyotos.mdwn
index cdf4e1bf..2340901d 100644
--- a/hurd/ng/microkernelcoyotos.mdwn
+++ b/hurd/ng/microkernelcoyotos.mdwn
@@ -2,7 +2,9 @@
 
 [Coyotos](http://www.coyotos.org/index.html) is a microkernel and OS and the successor of EROS, that itself is the successor of KeyKOS. A more complete history can be found [here](http://www.coyotos.org/history.html). Its main objectives are to correcte some shortcomings of EROS, demonstrate that an atomic kernel design scales well, and (eventually) to completely formally verify both the kernel and critical system components by writing them in a new language called [bitc](http://www.bitc-lang.org/).  [See [l4.verified](http://nicta.com.au/research/projects/l4.verified) for work on formally verifying an L4 microkernel.]
 
-Coyotos is an orthogonally persistent pure capability system. It uses continuation based unbuffered asynchronous IPC (actually it's synchronous IPC with asynchronous syscalls).
+Coyotos is an orthogonally persistent pure capability system. It uses
+continuation based unbuffered asynchronous IPC (actually it's synchronous IPC
+with asynchronous [[system calls]]).
 
 TODO: explain these terms and (more important) their consequences on system design.
 
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:
 
diff --git a/hurd/translator/wishlist_2.mdwn b/hurd/translator/wishlist_2.mdwn
index a927db55..77f39644 100644
--- a/hurd/translator/wishlist_2.mdwn
+++ b/hurd/translator/wishlist_2.mdwn
@@ -70,7 +70,17 @@ Here's an [idea](http://www.circlemud.org/~jelson/software/fusd/docs/node13.html
 
 * "One particularly interesting application of FUSD that we've found very useful is as a way to let regular user-space libraries export device file APIs. For example, imagine you had a library which factored large composite numbers. Typically, it might have a C interface--say, a function called `int *factorize(int bignum)`. With FUSD, it's possible to create a device file interface--say, a device called `/dev/factorize` to which clients can `write(2)` a big number, then `read(2)` back its factors.
 
-* This may sound strange, but device file APIs have at least three advantages over a typical library API. First, it becomes much more language independent--any language that can make system calls can access the factorization library. Second, the factorization code is running in a different address space; if it crashes, it won't crash or corrupt the caller. Third, and most interestingly, it is possible to use `select(2)` to wait for the factorization to complete. `select(2)` would make it easy for a client to factor a large number while remaining responsive to other events that might happen in the meantime. In other words, FUSD allows normal user-space libraries to integrate seamlessly with UNIX's existing, POSIX-standard event notification interface: `select(2)`."
+* This may sound strange, but device file APIs have at least three advantages
+  over a typical library API. First, it becomes much more language
+  independent--any language that can make [[system call]]s can access the
+  factorization library. Second, the factorization code is running in a
+  different address space; if it crashes, it won't crash or corrupt the
+  caller. Third, and most interestingly, it is possible to use `select(2)` to
+  wait for the factorization to complete. `select(2)` would make it easy for a
+  client to factor a large number while remaining responsive to other events
+  that might happen in the meantime. In other words, FUSD allows normal
+  user-space libraries to integrate seamlessly with UNIX's existing,
+  POSIX-standard event notification interface: `select(2)`."
 
 ## <a name="Mail"> Mail </a>