summaryrefslogtreecommitdiff
path: root/community/gsoc/project_ideas
diff options
context:
space:
mode:
authorantrik <antrik@users.sf.net>2011-03-16 03:29:06 +0100
committerantrik <antrik@users.sf.net>2011-03-25 23:32:12 +0100
commit99b52de704d58fd8bb6c5c65d500fb9812c8f873 (patch)
tree21150de226ca9c643f120af3a0dc54a0055ca1c9 /community/gsoc/project_ideas
parent70d256d2bd3fea95898383e7bcf6e90442cb6069 (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.mdwn2
-rw-r--r--community/gsoc/project_ideas/valgrind.mdwn8
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,