diff options
author | antrik <antrik@users.sf.net> | 2011-03-16 03:29:06 +0100 |
---|---|---|
committer | antrik <antrik@users.sf.net> | 2011-03-25 23:32:12 +0100 |
commit | 99b52de704d58fd8bb6c5c65d500fb9812c8f873 (patch) | |
tree | 21150de226ca9c643f120af3a0dc54a0055ca1c9 /community/gsoc/project_ideas | |
parent | 70d256d2bd3fea95898383e7bcf6e90442cb6069 (diff) |
gsoc/ideas: Add back () to function names
IMHO it's clearer that way -- especially in browsers that don't display
all text attributes, i.e. all text mode browsers.
Diffstat (limited to 'community/gsoc/project_ideas')
-rw-r--r-- | community/gsoc/project_ideas/secure_chroot.mdwn | 2 | ||||
-rw-r--r-- | community/gsoc/project_ideas/valgrind.mdwn | 8 |
2 files changed, 5 insertions, 5 deletions
diff --git a/community/gsoc/project_ideas/secure_chroot.mdwn b/community/gsoc/project_ideas/secure_chroot.mdwn index 57739861..bfaf330b 100644 --- a/community/gsoc/project_ideas/secure_chroot.mdwn +++ b/community/gsoc/project_ideas/secure_chroot.mdwn @@ -12,7 +12,7 @@ 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]]. diff --git a/community/gsoc/project_ideas/valgrind.mdwn b/community/gsoc/project_ideas/valgrind.mdwn index 79c8bd1d..5fa748ff 100644 --- a/community/gsoc/project_ideas/valgrind.mdwn +++ b/community/gsoc/project_ideas/valgrind.mdwn @@ -33,14 +33,14 @@ Compared to Linux, [[microkernel/Mach]] (the microkernel used by the Hurd) has very few kernel traps. Almost all [[system call]]s are implemented as [[RPC]]s instead -- either handled by Mach itself, or by the various [[Hurd servers|hurd/translator]]. -All RPCs use a pair of `mach_msg` invocations: +All RPCs use a pair of `mach_msg()` invocations: one to send a request message, and one to receive a reply. -However, while all RPCs use the same `mach_msg` trap, +However, while all RPCs use the same `mach_msg()` trap, the actual effect of the call varies greatly depending on which RPC is invoked -- -similar to the `ioctl` call on Linux. +similar to the `ioctl()` call on Linux. Each request thus must be handled individually. -Unlike `ioctl`, +Unlike `ioctl()`, the RPC invocations have explicit type information for the parameters though, which can be retrieved from the message header. By analyzing the parameters of the RPC reply message, |