summaryrefslogtreecommitdiff
path: root/community/gsoc/project_ideas/dtrace.mdwn
diff options
context:
space:
mode:
Diffstat (limited to 'community/gsoc/project_ideas/dtrace.mdwn')
-rw-r--r--community/gsoc/project_ideas/dtrace.mdwn67
1 files changed, 67 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..f7aeb6e8
--- /dev/null
+++ b/community/gsoc/project_ideas/dtrace.mdwn
@@ -0,0 +1,67 @@
+[[!meta copyright="Copyright © 2008, 2009, 2011, 2018 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="Kernel Instrumentation"]]
+
+[[!tag open_issue_gnumach]]
+
+[[!template id=highlight text="""/!\ Obsolete /!\
+
+---
+
+This is no longer valid as a Google Summer of Code project."""]]
+
+
+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
+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 [[open_issues/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 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.
+
+Exercise: Use the existing probes to perform some simple measurement.