Merge commit 'flubber/master'

8 files changed, 11 insertions, 51 deletions

diff --git a/community/gsoc/project_ideas/lexical_dot-dot.mdwn b/community/gsoc/project_ideas/lexical_dot-dot.mdwn
index f0b8db7c..764cd37f 100644
--- a/community/gsoc/project_ideas/lexical_dot-dot.mdwn
+++ b/community/gsoc/project_ideas/lexical_dot-dot.mdwn
@@ -31,7 +31,7 @@ mechanism.
 
 See also [[!GNU_Savannah_bug 17133]].
 
-Possible mentors: ?
+Possible mentors: Carl Fredrik Hammar (cfhammar)
 
 Exercise: This project requires changes to the name lookup mechanism in the
 Hurd-related glibc parts, as well as the Hurd servers. Thus, the exercise task
diff --git a/community/gsoc/project_ideas/mtab.mdwn b/community/gsoc/project_ideas/mtab.mdwn
index 045533e6..60dde525 100644
--- a/community/gsoc/project_ideas/mtab.mdwn
+++ b/community/gsoc/project_ideas/mtab.mdwn
@@ -67,7 +67,7 @@ implement both the actual [[mtab_translator|hurd/translator/mtabfs]], and the
 necessery interface(s) for gathering the data.  It requires getting a good
 understanding of the translator mechanism and Hurd interfaces in general.
 
-Possible mentors: Olaf Buddenhagen (antrik)
+Possible mentors: Olaf Buddenhagen (antrik), Carl Fredrik Hammar (cfhammar)
 
 Exercise: Make some improvement to any of the existing Hurd translators.
 Especially those in [hurdextras](http://www.nongnu.org/hurdextras/) are often
diff --git a/community/gsoc/project_ideas/secure_chroot.mdwn b/community/gsoc/project_ideas/secure_chroot.mdwn
index a433e8d1..0a08bbf5 100644
--- a/community/gsoc/project_ideas/secure_chroot.mdwn
+++ b/community/gsoc/project_ideas/secure_chroot.mdwn
@@ -38,7 +38,7 @@ new mechanisms.  (Translators.)  More important than the actual code is the
 documentation of what he did: he must be able to defend why he chose a certain
 approach, and explain why he believes this approach really secure.
 
-Possible mentors: ?
+Possible mentors: Carl Fredrik Hammar (cfhammar)
 
 Exercise: It's hard to come up with a relevant exercise, as there are so many
 possible solutions... Probably best to make an improvement to one of the
diff --git a/community/gsoc/project_ideas/server_overriding.mdwn b/community/gsoc/project_ideas/server_overriding.mdwn
index 42edf287..80beab4c 100644
--- a/community/gsoc/project_ideas/server_overriding.mdwn
+++ b/community/gsoc/project_ideas/server_overriding.mdwn
@@ -68,7 +68,7 @@ discussing this topic, from a previous year's GSoC application -- see
 <http://lists.gnu.org/archive/html/bug-hurd/2007-06/msg00082.html>,
 <http://lists.gnu.org/archive/html/bug-hurd/2008-03/msg00039.html>.
 
-Possible mentors: Olaf Buddenhagen (antrik)
+Possible mentors: Olaf Buddenhagen (antrik), Carl Fredrik Hammar (cfhammar)
 
 Exercise: Come up with a glibc patch that allows overriding one specific
 standard server using method (1).
diff --git a/community/gsoc/project_ideas/tmpfs.mdwn b/community/gsoc/project_ideas/tmpfs.mdwn
index 69adef0f..93215d07 100644
--- a/community/gsoc/project_ideas/tmpfs.mdwn
+++ b/community/gsoc/project_ideas/tmpfs.mdwn
@@ -37,7 +37,7 @@ implementation.  It requires digging into some parts of the Hurd, including the
 [[pager_interface|hurd/libpager]] and [[hurd/translator]] programming.  This
 task probably doesn't require any design work, only good debugging skills.
 
-Possible mentors: ?
+Possible mentors: Carl Fredrik Hammar (cfhammar)
 
 Exercise: Take a look at tmpfs and try to fix one of the existing issues. Some
 of them are probably not too tricky; or you might discover something else you
diff --git a/community/gsoc/project_ideas/unionfs_boot.mdwn b/community/gsoc/project_ideas/unionfs_boot.mdwn
index a801290f..6c83092b 100644
--- a/community/gsoc/project_ideas/unionfs_boot.mdwn
+++ b/community/gsoc/project_ideas/unionfs_boot.mdwn
@@ -42,4 +42,4 @@ Completing this task will require gaining a very good understanding of the Hurd
 boot process and other parts of the design.  It requires some design skills
 also to come up with a working mechanism.
 
-Possible mentors: ?
+Possible mentors: Carl Fredrik Hammar (cfhammar)
diff --git a/community/gsoc/project_ideas/virtualization.mdwn b/community/gsoc/project_ideas/virtualization.mdwn
index c7403f70..3a677306 100644
--- a/community/gsoc/project_ideas/virtualization.mdwn
+++ b/community/gsoc/project_ideas/virtualization.mdwn
@@ -73,4 +73,4 @@ Completing this project will require gaining a very good understanding of the
 Hurd architecture and spirit. Previous experience with other virtualization
 solutions would be very helpful.
 
-Possible mentors: Olaf Buddenhagen (antrik)
+Possible mentors: Olaf Buddenhagen (antrik), Carl Fredrik Hammar (cfhammar)
diff --git a/community/gsoc/xorg_ideas.mdwn b/community/gsoc/xorg_ideas.mdwn
index 406d370d..26177345 100644
--- a/community/gsoc/xorg_ideas.mdwn
+++ b/community/gsoc/xorg_ideas.mdwn
@@ -8,51 +8,11 @@ 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]]."]]"""]]
 
-## libpciaccess Support for GNU Hurd
-
-xserver 1.5 introduces libpciaccess as a new method for handling PCI devices.
-The purpose was to get rid of the messy old PCI code in the server, instead
-using a new implementation that is encapsulated in a library, and uses external
-PCI access interfaces provided by the operating systems.
-
-As libpciaccess is written from scratch, support for various operating systems
-needs to be reimplemented individually, writing specific backends for each.
-This task is about creating such a backend for GNU Hurd.
-
-Writing a "proper" native backend for the Hurd is rather involved, as there is
-no kernel PCI interface so far -- it has to be created first. It would also
-have the disadvantage of being somewhat tied to the specific driver framework:
-The present framework is pretty dated (using some ancient Linux drivers with a
-layer of glue code); and when this is replaced, the PCI interface will have to
-be updated as well.
-
-Alternatively, a libpciaccess backend simply doing old-style register poking
-from user space could be implemented. (Either from scratch, or by reusing some
-existing PCI code from the old server or some BSD kernel.) That approach is not
-as elegant; it would be somewhat fragile and limited, like the old PCI code in
-the server. On the other hand, it is much simpler to implement; and it would
-also benefit other non-mainstream platforms that can't afford
-creating/maintaining a native backend.
-
-The goal of this project is getting a recent xorg server, using libpciaccess,
-to run on the Hurd.
-
-This task probably doesn't require any previous X programming knowledge, though
-a bit of experience with PCI programming will probably help. Some Hurd-specific
-knowledge will have to be obtained while working on it -- especially if
-implementing a proper kernel PCI interface. The task is pretty involved in the
-latter case, but shouldn't be too hard if taking the user space register poking
-approach.
-
-Exercise: Implement a stub backend for libpciaccess, which doesn't really do
-anything useful, but compiles fine on the Hurd.
-
-
 ## VT Switching for GNU Hurd
 
 While XFree86 was first ported to the Hurd more than a decade ago, and there
-are updates now and then to make newer versions of Xorg run as well (see also
-the libpciaccess task), the support is quite rudimentary: in particular, there
+are updates now and then to make newer versions of Xorg run as well,
+the support is quite rudimentary: in particular, there
 is no support for switching back to the text console while X is running.
 
 Implementing this requires creating an interface between the X server and the
@@ -74,7 +34,7 @@ The Direct Rendering Manager (DRM) is a kernel driver component taking care of
 graphics hardware access. Originally, it only took care of the 3D acceleration
 unit, and was used mostly by the DRI (Direct Rendering Infrastructure) in Mesa.
 
-About two years ago, the developers came to the conclusion that a more robust
+A few years ago, the developers came to the conclusion that a more robust
 and functional graphics stack requires the kernel driver to take care of other
 graphics access as well: mode setting in particular. (Essentially what the old
 KGI project proposed, see <http://www.kgi-project.org>.) Also, with the new GEM
@@ -90,7 +50,7 @@ microkernel idea -- we want to run the drivers as priviledged user space server
 processes, rather than actual kernel modules.
 
 This task is about doing the first steps for porting the DRM to the Hurd. This
-can be done by taking one of the existing DRM modesetting drivers (Intel or
+can be done by taking one of the existing DRM modesetting drivers (Intel, Nouveau (Nvidia), or
 Radeon), trying to get parts of it running as a Hurd server, and
 porting/implementing necessary pieces of the general DRM framework as needed
 along the way.