community/gsoc/project_ideas/dtrace -> open_issues/dtrace.

1 files changed, 0 insertions, 49 deletions

diff --git a/community/gsoc/project_ideas/dtrace.mdwn b/community/gsoc/project_ideas/dtrace.mdwn
deleted file mode 100644
index 6448d563..00000000
--- a/community/gsoc/project_ideas/dtrace.mdwn
+++ /dev/null
@@ -1,49 +0,0 @@
-[[!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: [[LTTng]]
-
-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.