2 files changed, 32 insertions, 20 deletions
diff --git a/community/gsoc/project_ideas.mdwn b/community/gsoc/project_ideas.mdwn
index b4b60dd6..0c249b62 100644
--- a/community/gsoc/project_ideas.mdwn
+++ b/community/gsoc/project_ideas.mdwn
@@ -108,3 +108,4 @@ See also the list of [Hurd-related X.org project ideas](http://wiki.x.org/wiki/H
 [[!inline pages="community/gsoc/project_ideas/xattr" show=0 feeds=no actions=yes]]
 [[!inline pages="community/gsoc/project_ideas/valgrind" show=0 feeds=no actions=yes]]
 [[!inline pages="community/gsoc/project_ideas/driver_glue_code" show=0 feeds=no actions=yes]]
+[[!inline pages="community/gsoc/project_ideas/dtrace" show=0 feeds=no actions=yes]]
diff --git a/community/gsoc/project_ideas/dtrace.mdwn b/community/gsoc/project_ideas/dtrace.mdwn
index ebb63d48..f70598ca 100644
--- a/community/gsoc/project_ideas/dtrace.mdwn
+++ b/community/gsoc/project_ideas/dtrace.mdwn
@@ -9,7 +9,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]]."]]"""]]
 
-[[!meta title="dtrace Support"]]
+[[!meta title="Kernel Instrumentation"]]
 
 One of the main problems of the current Hurd implementation is very poor
 [[open_issues/performance]]. While we have a bunch of ideas what could cause the performance
@@ -25,25 +25,36 @@ situations occur, how things interact, etc. It could also prove helpful in
 debugging some issues that are otherwise hard to find because of complex
 interactions.
 
-The most popular framework for that is Sun's dtrace; but there might be others.
-The student has to evaluate the existing options, deciding which makes most
-sense for the Hurd; and implement that one. (Apple's implementation of dtrace
-in their Mach-based kernel might be helpful here...)
-
-This project requires ability to evaluate possible solutions, and experience
-with integrating existing components as well as low-level programming.
+The most popular kernel instrumentation framework is Sun's dtrace,
+originally written for Solaris,
+but also adopted by some other systems.
+However, the GPL-incompatible license means it can't be used in Linux,
+and thus Linux developers created their own frameworks instead:
+first [[SystemTap]], and now [[LTTng]].
+
+In 2008, Andrei Barbu did initial work on kernel probes for the Hurd.
+However, not all of his patches got merged,
+because some turned out not to be fully functional.
+Also, he didn't get around to work on userspace probes,
+nor on a nice frontend for writing test scripts employing the probes.
+
+The goal of this project is to make the instrumentation framework
+more usable and complete,
+and to better integrate it in the Hurd.
+For that, the student will have to work
+on some real profiling and/or debugging tasks,
+and fix any shortcomings he encounters in the framework.
+
+This is a pretty involved task.
+Previous experience with low-level programming is a must;
+and it also requires a good grasp on interactions in complex systems.
+
+To work on this project,
+the student will have to get familiar with GNU Mach.
+(The microkernel employed by the Hurd.)
+Some understanding of other aspects of the Hurd will also be required,
+depending on the exact nature of the profiling/debugging performed.
 
 Possible mentors: Samuel Thibault (youpi)
 
-Related: [[profiling]], [[LTTng]], [[SystemTap]]
-
-Exercise: In lack of a good exercise directly related to this task, just pick
-one of the kernel-related or generally low-level tasks from the bug/task
-trackers on savannah, and make a go at it. You might not be able to finish the
-task in a limited amount of time, but you should at least be able to make a
-detailed analysis of the issue.
-
-*Status*: Andei Barbu was working on
-[SystemTap](http://csclub.uwaterloo.ca/~abarbu/hurd/) for GSoC 2008, but it
-turned out too Linux-specific. He implemented kernel probes, but there is no
-nice frontend yet.
+Exercise: Use the existing probes to perform some simple measurement.