From 8ee6975b7c1c0557d21ca966c24ea09806104498 Mon Sep 17 00:00:00 2001 From: antrik Date: Fri, 25 Mar 2011 00:07:28 +0100 Subject: gsoc/ideas/driver_glue_code: Update and add back As zhengda seems MIA, this task is up for takers again. Update the text to reflect the fact that zhengda already did a lot of the DDE work. (Actually, the text is almost entirely rewritten...) Probably this should be split into several distinct tasks for the various aspects that need work. --- community/gsoc/project_ideas.mdwn | 1 + community/gsoc/project_ideas/driver_glue_code.mdwn | 84 ++++++++++++++-------- 2 files changed, 54 insertions(+), 31 deletions(-) diff --git a/community/gsoc/project_ideas.mdwn b/community/gsoc/project_ideas.mdwn index 8d31ed7f..b4b60dd6 100644 --- a/community/gsoc/project_ideas.mdwn +++ b/community/gsoc/project_ideas.mdwn @@ -107,3 +107,4 @@ See also the list of [Hurd-related X.org project ideas](http://wiki.x.org/wiki/H [[!inline pages="community/gsoc/project_ideas/libcap" show=0 feeds=no actions=yes]] [[!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]] 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. + + +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...) -- cgit v1.2.3 From b2958678e344de739216ec3769e770fb3b9a524f Mon Sep 17 00:00:00 2001 From: antrik Date: Fri, 25 Mar 2011 10:15:46 +0100 Subject: gsoc/ideas/dtrace: fix broken links --- community/gsoc/project_ideas/dtrace.mdwn | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/community/gsoc/project_ideas/dtrace.mdwn b/community/gsoc/project_ideas/dtrace.mdwn index 252c303a..ebb63d48 100644 --- a/community/gsoc/project_ideas/dtrace.mdwn +++ b/community/gsoc/project_ideas/dtrace.mdwn @@ -12,12 +12,12 @@ 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 +[[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 [[profiling]] tools could be conceived, the most promising and +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 -- cgit v1.2.3 From ee947ab4eff2bda9bc6409ed69f6f68b5164602e Mon Sep 17 00:00:00 2001 From: antrik Date: Fri, 25 Mar 2011 10:20:54 +0100 Subject: gsoc/ideas/dtrace: Update and add back Doesn't look like Andrei will ever continue work on this, so it's up for takers again. Mention previous work, and update task accordingly. --- community/gsoc/project_ideas.mdwn | 1 + community/gsoc/project_ideas/dtrace.mdwn | 51 +++++++++++++++++++------------- 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. -- cgit v1.2.3