Merge commit 'ee947ab4eff2bda9bc6409ed69f6f68b5164602e'

Conflicts:
	community/gsoc/project_ideas/dtrace.mdwn

2 files changed, 84 insertions, 51 deletions

diff --git a/community/gsoc/project_ideas/driver_glue_code.mdwn b/community/gsoc/project_ideas/driver_glue_code.mdwn
index 9c063e9f..65ea4f0f 100644
--- a/community/gsoc/project_ideas/driver_glue_code.mdwn
+++ b/community/gsoc/project_ideas/driver_glue_code.mdwn
@@ -1,5 +1,4 @@
-[[!meta copyright="Copyright © 2008, 2009, 2010 Free Software Foundation,
-Inc."]]
+[[!meta copyright="Copyright © 2008, 2009, 2010, 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
@@ -9,41 +8,64 @@ 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="New Driver Glue Code"]]
+[[!meta title="New Driver Framework"]]
 
-Although a driver framework in user space would be desirable, presently the Hurd
-uses kernel drivers in the microkernel,
-[[GNU_Mach|microkernel/mach/gnumach]]. (And changing this would be far beyond a
-GSoC project...)
-
-The problem is that the drivers in GNU Mach are presently old Linux drivers
-(mostly from 2.0.x) accessed through a glue code layer. This is not an ideal
-solution, but works quite OK, except that the drivers are very old. The goal of
-this project is to redo the glue code, so we can use drivers from current Linux
-versions, or from one of the free BSD variants.
-
-While it would be certainly possible to create custom glue code again, a more
-sustainable and probably also easier approach is to use
-[[DDE]] instead -- it already
-does the hard work of providing an environment where the foreign drivers can
-run, and has the additional advantage of being externally maintained.
-
-This is a doable, but pretty involved project. Previous experience with driver
-programming probably is a must. (No Hurd-specific knowledge is required,
-though.)
+The Hurd presently uses hardware drivers
+implemented in the microkernel, [[GNU_Mach|microkernel/mach/gnumach]].
+These drivers are old Linux drivers (mostly from 2.0.x)
+accessed through a glue code layer.
+This is not an ideal solution, but works quite OK,
+except that the drivers are extremely old by now.
+Thus we need a new framework,
+so we can use drivers from current Linux versions instead,
+or perhaps from one of the free BSD variants.
 
 This is [[!GNU_Savannah_task 5488]].
 [[open issues/user-space device drivers]].
 [[open issues/device drivers and io systems]].
 
+The most promising approach for getting newer drivers seems to be [[DDE]]:
+it already does the hard work of providing an environment
+where the foreign drivers can run,
+and offers the additional benefit of being externally maintained.
+DDE also offers the necessary facilities
+for running all drivers in separate userspace processes,
+which is more desirable than drivers running in the microkernel.
 
-Possible mentors: Samuel Thibault (youpi)
+[[Zheng Da|zhengda]] has already done considerable work on this.
+The basic framework for using DDE in the Hurd is present,
+and network card drivers are already working very well.
+However, this work isn't fully integrated in the Hurd yet.
+The additional kernel interfaces that were created for this
+are still prototypes, and will need to be reworked.
+Also, there is no build system for automatically compiling
+all Linux network card drivers in one go.
+
+Other types of drivers are missing so far.
+Support for IDE drivers has been partially implemented,
+but isn't fully working yet.
+To fully replace the old in-kernel drivers,
+further infrastructure will be necessary
+to make userspace disk drivers usable for the root filesystem.
 
-Exercise: Take a driver for some newer piece of hardware (e.g. Intel e1000
-ethernet) from a recent system, and try to port it to run in the existing
-driver framework in GNU Mach. Completing the port might be too involved for the
-exercise; but it's pretty likely that you will find something else to improve
-in the glue code while working on this...
+Some other subsystems are missing or incomplete in DDE itself,
+and will require additional work that is not specific to the Hurd implementation.
+
+The goal of this task is to fix at least one of the mentioned major shortcomings:
+rework the kernel interfaces;
+provide a streamlined build system for the drivers;
+finish IDE support;
+or implement support for some other subsystem.
+<!-- should probably provide separate task descriptions for each... -->
+
+This is a doable, but pretty involved project.
+Previous experience with driver programming probably is a must.
+To be able to work on the framework,
+the student will also have to get a good understanding of certain aspects of Hurd,
+such as memory management for example.
+
+Possible mentors: Samuel Thibault (youpi)
 
-*Status*: [[Zheng Da|zhengda]] is working on DDE, and has mostly completed the
-initial port.
+Exercise: Get one of the not yet integrated Linux network card drivers to work.
+(Note: This should be straightforward,
+once you have the framework properly built and set up...)
diff --git a/community/gsoc/project_ideas/dtrace.mdwn b/community/gsoc/project_ideas/dtrace.mdwn
index 8fd3231f..6261c03e 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"]]
 
 [[!tag open_issue_gnumach]]
 
@@ -27,25 +27,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: [[open_issues/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.