gsoc/project_ideas: Restore all project ideas here

While there is certainly some overlap with other areas, it is *not*
acceptable to drop mentors and exercises from GSoC tasks, nor to add
random crap, nor do any other changes that make them less useful as GSoC
tasks -- and this is *not* obvious if they do not live in the
project_ideas namespace. It's also confusing in general.

I tried to preserve all valid changes to the task descriptions themself
-- though I might have messed up some things.

I did leave the now redundant entries in open_tasks in place. Not sure
how to deal with them. As the content is virtually identical anyways,
they probably should be just turned into stubs pointing here. Or don't
list them explicitely at all -- we point out in other places that GSoC
ideas are useful in other contexts too...

For the future, please refrain from reorganising things here without
prior discussion.

1 files changed, 49 insertions, 0 deletions

diff --git a/community/gsoc/project_ideas/dtrace.mdwn b/community/gsoc/project_ideas/dtrace.mdwn
new file mode 100644
index 00000000..252c303a
--- /dev/null
+++ b/community/gsoc/project_ideas/dtrace.mdwn
@@ -0,0 +1,49 @@
+[[!meta copyright="Copyright © 2008, 2009, 2011 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]]."]]"""]]
+
+[[!meta title="dtrace Support"]]
+
+One of the main problems of the current Hurd implementation is very poor
+[[performance]]. While we have a bunch of ideas what could cause the performance
+problems, these are mostly just guesses. Better understanding what really
+causes bad performance is necessary to improve the situation.
+
+For that, we need tools for performance measurements. While all kinds of more
+or less specific [[profiling]] tools could be conceived, the most promising and
+generic approach seems to be a framework for logging certain events in the
+running system (both in the microkernel and in the Hurd servers). This would
+allow checking how much time is spent in certain modules, how often certain
+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.
+
+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.