diff options
| -rw-r--r-- | community/gsoc/project_ideas/libcap.mdwn | 8 | ||||
| -rw-r--r-- | community/gsoc/project_ideas/libcap/details.mdwn | 8 | ||||
| -rw-r--r-- | community/gsoc/project_ideas/secure_chroot.mdwn | 11 | ||||
| -rw-r--r-- | community/gsoc/project_ideas/valgrind.mdwn | 8 | ||||
| -rw-r--r-- | extensibility.mdwn | 9 | ||||
| -rw-r--r-- | faq/sharing_the_user_space.mdwn | 2 | ||||
| -rw-r--r-- | glibc.mdwn | 13 | ||||
| -rw-r--r-- | glibc/fork.mdwn | 20 | ||||
| -rw-r--r-- | hurd/glibc/hurd-specific_api.mdwn | 11 | ||||
| -rw-r--r-- | hurd/networking.mdwn | 11 | ||||
| -rw-r--r-- | hurd/ng/microkernelcoyotos.mdwn | 4 | ||||
| -rw-r--r-- | hurd/ng/trivialconfinementvsconstructorvsfork.mdwn | 18 | ||||
| -rw-r--r-- | hurd/translator/wishlist_2.mdwn | 12 | ||||
| -rw-r--r-- | qemu.mdwn | 12 | ||||
| -rw-r--r-- | system_call.mdwn | 19 |
15 files changed, 113 insertions, 53 deletions
diff --git a/community/gsoc/project_ideas/libcap.mdwn b/community/gsoc/project_ideas/libcap.mdwn index 1346203d..18c49c48 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 aa27a84e..85695978 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 feb30a7c..57739861 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 c6fc7459..7d68e82d 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 01b1f3b1..17cd5e51 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 7d09ccc0..ec880827 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, @@ -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 c9efd1f4..e8556a91 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 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> @@ -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 00000000..197889cb --- /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]]. |