summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
-rw-r--r--community/gsoc/project_ideas/libcap.mdwn8
-rw-r--r--community/gsoc/project_ideas/libcap/details.mdwn8
-rw-r--r--community/gsoc/project_ideas/secure_chroot.mdwn11
-rw-r--r--community/gsoc/project_ideas/valgrind.mdwn8
-rw-r--r--extensibility.mdwn9
-rw-r--r--faq/sharing_the_user_space.mdwn2
-rw-r--r--glibc.mdwn13
-rw-r--r--glibc/fork.mdwn20
-rw-r--r--hurd/glibc/hurd-specific_api.mdwn11
-rw-r--r--hurd/networking.mdwn11
-rw-r--r--hurd/ng/microkernelcoyotos.mdwn4
-rw-r--r--hurd/ng/trivialconfinementvsconstructorvsfork.mdwn18
-rw-r--r--hurd/translator/wishlist_2.mdwn12
-rw-r--r--qemu.mdwn12
-rw-r--r--system_call.mdwn19
15 files changed, 113 insertions, 53 deletions
diff --git a/community/gsoc/project_ideas/libcap.mdwn b/community/gsoc/project_ideas/libcap.mdwn
index 1346203..18c49c4 100644
--- a/community/gsoc/project_ideas/libcap.mdwn
+++ b/community/gsoc/project_ideas/libcap.mdwn
@@ -1,12 +1,12 @@
-[[!meta copyright="Copyright © 2009 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2009, 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="Implementing libcap"]]
@@ -33,7 +33,7 @@ probably doable without previous experience with either, though.
David Hedberg applied for this project in 2010,
and though he didn't go through with it,
-he fleshed out many [[libcap/details]].
+he fleshed out many [[details]].
Possible mentors: Samuel Thibault (youpi)
diff --git a/community/gsoc/project_ideas/libcap/details.mdwn b/community/gsoc/project_ideas/libcap/details.mdwn
index aa27a84..8569597 100644
--- a/community/gsoc/project_ideas/libcap/details.mdwn
+++ b/community/gsoc/project_ideas/libcap/details.mdwn
@@ -5,8 +5,8 @@ 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="Details on implementing libcap"]]
@@ -59,7 +59,7 @@ Each process has a three bit fields representing each of the three
sets (P, E and I). Each bit field is currently built up of two (32
bit) integers to be able to hold the 33 currently defined capabilities
(see linux/capability.h). Each process further has a bounding set which
-bounds the permitted set. Two syscalls handles the setting and getting
+bounds the permitted set. Two [[system call]]s handles the setting and getting
of capabilities; *capset* and *capget*. Some related functionality
can also be controlled by calling *prctl*: the right to read/drop the
bounding capabilities (PR_CAPBSET_READ/PR_CAPBSET_DROP) and whether
@@ -428,7 +428,7 @@ the following (also detailed somewhat in the same article):
* Execute process as root (or setuid) to gain all capabilities.
-* Use the prctl system call to enable keepcaps for the process
+* Use the prctl [[system call]] to enable keepcaps for the process
(same(?) effect as enabling SECURE_NO_SETUID_FIXUP for the process).
keepcaps should be off by default.
diff --git a/community/gsoc/project_ideas/secure_chroot.mdwn b/community/gsoc/project_ideas/secure_chroot.mdwn
index feb30a7..5773986 100644
--- a/community/gsoc/project_ideas/secure_chroot.mdwn
+++ b/community/gsoc/project_ideas/secure_chroot.mdwn
@@ -1,17 +1,18 @@
-[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2008, 2009, 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="Secure chroot Implementation"]]
As the Hurd attempts to be (almost) fully [[UNIX]]-compatible, it also implements a
-`chroot()` system call. However, the current implementation is not really
+`chroot` [[system call]]. However, the current implementation is not really
good, as it allows easily escaping the `chroot`, for example by use of
[[passive_translators|hurd/translator]].
@@ -20,7 +21,7 @@ workaround changing the behavior of passive translators in a `chroot`;
changing the context in which passive translators are executed; changing the
interpretation of filenames in a chroot; to reworking the whole passive
translator mechanism. Some involving a completely different approach to
-`chroot` implementation, using a proxy instead of a special system call in the
+`chroot` implementation, using a proxy instead of a special [[system call]] in the
filesystem servers.
See <http://tri-ceps.blogspot.com/2007/07/theory-of-filesystem-relativity.html>
diff --git a/community/gsoc/project_ideas/valgrind.mdwn b/community/gsoc/project_ideas/valgrind.mdwn
index c6fc745..7d68e82 100644
--- a/community/gsoc/project_ideas/valgrind.mdwn
+++ b/community/gsoc/project_ideas/valgrind.mdwn
@@ -18,7 +18,7 @@ although they work on Linux.
Even more importantly, it will help finding bugs in the Hurd servers themselfs.
To keep track of memory use,
-Valgrind however needs to know how each system call affects the validity of memory regions.
+Valgrind however needs to know how each [[system call]] affects the validity of memory regions.
This knowledge is highly kernel-specific,
and thus Valgrind needs to be explicitely ported for every system.
@@ -26,11 +26,11 @@ Such a port involves two major steps:
making Valgrind understand how kernel traps work in general on the system in question;
and how all the individual kernel calls affect memory.
The latter step is where most of the work is,
-as the behaviour of each single system call needs to be described.
+as the behaviour of each single [[system call]] needs to be described.
Compared to Linux,
Mach (the microkernel used by the Hurd) has very few kernel traps.
-Almost all system calls are implemented as RPCs instead --
+Almost all [[system call]]s are implemented as RPCs instead --
either handled by Mach itself, or by the various Hurd servers.
All RPCs use a pair of mach\_msg() invocations:
one to send a request message, and one to receive a reply.
@@ -62,7 +62,7 @@ The goal of this task is at minimum to make Valgrind grok Mach traps,
and to implement the generic RPC handler.
Ideally, specific handling for RPCs needing it should also be implemented.
-Completing this project will require digging into Valgrind's handling of system calls,
+Completing this project will require digging into Valgrind's handling of [[system call]]s,
and into Hurd RPCs.
It is not an easy task, but a fairly predictable one --
there shouldn't be any unexpected difficulties,
diff --git a/extensibility.mdwn b/extensibility.mdwn
index 01b1f3b..17cd5e5 100644
--- a/extensibility.mdwn
+++ b/extensibility.mdwn
@@ -1,17 +1,18 @@
-[[!meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 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]]."]]"""]]
An extensible system is one that enables extensibility. Enabling extensibility
means providing non-privileged mechanisms to extend existing objects and to
introduce new objects. [[UNIX]] is generally not an extensible system as it does
-not generally facilitate the hooking of system calls. For instance, there is
+not generally facilitate the hooking of [[system call]]s. For instance, there is
no way to hook into the virtual file system. This has motivated the introduction
of separate, parallel interfaces by both the GNOME and KDE projects to provide
users a more integrated view of their objects.
diff --git a/faq/sharing_the_user_space.mdwn b/faq/sharing_the_user_space.mdwn
index 7d09ccc..ec88082 100644
--- a/faq/sharing_the_user_space.mdwn
+++ b/faq/sharing_the_user_space.mdwn
@@ -15,7 +15,7 @@ everything but the kernel is shared?
*Answer:* Given that both Linux and GNU Hurd are using the [[ELF]] binary
format, this could indeed be made possible, if all programs agreed to rely on
only one abstraction layer, for example the standard C library ([[glibc]]).
-(Additionally, for example for system calls that are not covered by glibc
+(Additionally, for example for [[system call]]s that are not covered by glibc
calls, you'd need to be able to reliably trap and emulate these.) However,
Linux' and the GNU Hurd's [[ABI]]'s have sufficiently diverged, so that this is
not easy to do. That's why you can't currently install a system in this way,
diff --git a/glibc.mdwn b/glibc.mdwn
index f47efc0..2eba366 100644
--- a/glibc.mdwn
+++ b/glibc.mdwn
@@ -6,8 +6,8 @@ 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="GNU C Library"]]
@@ -31,6 +31,15 @@ Porting glibc to a specific architecture is non-trivial.
# Implementation Details
+ * [[hurd/glibc/Hurd-specific API]]
+
+ * [[open_issues/secure_file_descriptor_handling]]
+
+
+## Individual functions
+
+Some of these are well-known as [[UNIX]] [[system call]]s.
+
* [[environment_variables]]
* [[fork]]
diff --git a/glibc/fork.mdwn b/glibc/fork.mdwn
index c9efd1f..e8556a9 100644
--- a/glibc/fork.mdwn
+++ b/glibc/fork.mdwn
@@ -8,7 +8,7 @@ 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]]."]]"""]]
-On [[Unix]] systems, `fork` is a rather simple system call.
+On [[Unix]] systems, `fork` is a rather simple [[system call]].
Our implementation in [[glibc]] is and needs to be rather bulky.
@@ -22,12 +22,13 @@ which requires a small number of [[RPC]] for each of them.
In sum, [[this affects performance|open_issues/performance/fork]] when new
processes are continuously being spawned from the shell, for example.
-Often, a `fork` call will eventually be followed by an `exec`, which will in
-turn close (most of) the duplicated port rights. Unfortunately, this cannot be
-known at the time the `fork` executing, so the code calling `fork` has to be
-modified, and the `fork`, `exec` combo be replaced by a `posix_spawn` call, for
-example, to avoid this work of duplicating each port right, then closing each
-again.
+Often, a `fork` call will eventually be followed by an `exec`, which [[may in
+turn close|open_issues/secure_file_descriptor_handling]] (most of) the
+duplicated port rights. Unfortunately, this cannot be known at the time the
+`fork` executing, so in order to optimize this, the code calling `fork` has to
+be modified instead, and the `fork`, `exec` combo be replaced by a
+`posix_spawn` call, for example, to avoid this work of duplicating each port
+right, then closing each again.
As far as we know, Cygwin has the same problem of `fork` being a nontrivial
operation. Perhaps we can learn from what they're been doing? Also, perhaps
@@ -51,6 +52,11 @@ they have patches for software packages, to avoid using `fork` followed by
([[!taglink open_issue_glibc]]).
+## Related
+
+ * [[secure file descriptor handling]].
+
+
# External
* [*How fork(2) ought to be*](http://www.greenend.org.uk/rjk/fork.html) by
diff --git a/hurd/glibc/hurd-specific_api.mdwn b/hurd/glibc/hurd-specific_api.mdwn
index aeb63d9..7522027 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 ff16eb2..bdf9def 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 cdf4e1b..2340901 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 4eeef6e..0d91dee 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 a927db5..77f3964 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>
diff --git a/qemu.mdwn b/qemu.mdwn
index 19b5fb9..d7cea5a 100644
--- a/qemu.mdwn
+++ b/qemu.mdwn
@@ -1,13 +1,13 @@
-[[!meta copyright="Copyright © 2005, 2007, 2008, 2009 Free Software Foundation,
-Inc."]]
+[[!meta copyright="Copyright © 2005, 2007, 2008, 2009, 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]]."]]"""]]
QEMU is free software written by Fabrice Bellard that implements a fast
processor [[emulator|emulation]], allowing a user to run one operating system
@@ -19,8 +19,8 @@ reasonable speed while being easy to port on new host CPUs.
QEMU has two operating modes:
* User mode emulation: QEMU can launch Linux processes compiled for one CPU
- on another CPU. Linux system calls are converted because of endianness and
- 32/64 bit mismatches. Wine and Dosemu are the main targets for QEMU.
+ on another CPU. Linux [[system call]]s are converted because of endianness
+ and 32/64 bit mismatches. Wine and Dosemu are the main targets for QEMU.
* System mode emulation: QEMU emulates a full system, including a processor
and various peripherials. It enables easier testing and debugging of
diff --git a/system_call.mdwn b/system_call.mdwn
new file mode 100644
index 0000000..197889c
--- /dev/null
+++ b/system_call.mdwn
@@ -0,0 +1,19 @@
+[[!meta copyright="Copyright © 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]]."]]"""]]
+
+In an [[UNIX]]-like system, a *system call* (*syscall*) is used to request all
+kinds of functionality from the operating system kernel.
+
+A [[microkernel]]-based system typically won't offer a lot of system calls --
+apart from one central one, and that is *send message* -- but instead [[RPC]]s
+will be used instead.
+
+In the [[GNU Hurd|hurd]], a lot of what is traditionlly considered to be a UNIX
+system call is implemented (primarily by means of [[RPC]]) inside [[glibc]].