Diffstat (limited to 'community/gsoc/project_ideas/valgrind.mdwn')
1 files changed, 4 insertions, 4 deletions
diff --git a/community/gsoc/project_ideas/valgrind.mdwn b/community/gsoc/project_ideas/valgrind.mdwn
index c6fc7459..7d68e82d 100644
@@ -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,