5 files changed, 63 insertions, 20 deletions
diff --git a/community/gsoc/project_ideas.mdwn b/community/gsoc/project_ideas.mdwn
index 030c18f3..8d31ed7f 100644
--- a/community/gsoc/project_ideas.mdwn
+++ b/community/gsoc/project_ideas.mdwn
@@ -76,20 +76,12 @@ will assist you as well as we can.
 
 See also the list of [Hurd-related X.org project ideas](http://wiki.x.org/wiki/Hurd_Porting).
 
-Here is a list of what we consider suitable tasks:
-
-[[!map show=title pages="(community/gsoc/project_ideas/* and
-  !community/gsoc/project_ideas/*/*) or tagged(gsoc-task)"]]
-
-Here are these pages' content:
-
 [[!inline pages="community/gsoc/project_ideas/language_bindings" show=0 feeds=no actions=yes]]
 [[!inline pages="community/gsoc/project_ideas/virtualization" show=0 feeds=no actions=yes]]
 [[!inline pages="community/gsoc/project_ideas/file_locking" show=0 feeds=no actions=yes]]
 [[!inline pages="community/gsoc/project_ideas/server_overriding" show=0 feeds=no actions=yes]]
 [[!inline pages="community/gsoc/project_ideas/tcp_ip_stack" show=0 feeds=no actions=yes]]
 [[!inline pages="community/gsoc/project_ideas/nfs" show=0 feeds=no actions=yes]]
-[[!inline pages="community/gsoc/project_ideas/libdiskfs_locking" show=0 feeds=no actions=yes]]
 [[!inline pages="community/gsoc/project_ideas/pthreads" show=0 feeds=no actions=yes]]
 [[!inline pages="community/gsoc/project_ideas/sound" show=0 feeds=no actions=yes]]
 [[!inline pages="community/gsoc/project_ideas/disk_io_performance" show=0 feeds=no actions=yes]]
@@ -111,7 +103,7 @@ Here are these pages' content:
 [[!inline pages="community/gsoc/project_ideas/cdparanoia" show=0 feeds=no actions=yes]]
 [[!inline pages="community/gsoc/project_ideas/perl_python" show=0 feeds=no actions=yes]]
 [[!inline pages="community/gsoc/project_ideas/testsuites" show=0 feeds=no actions=yes]]
-[[!inline pages="open_issues/unit_testing" show=0 feeds=no actions=yes]]
+[[!inline pages="community/gsoc/project_ideas/testing_framework" show=0 feeds=no actions=yes]]
 [[!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]]
diff --git a/community/gsoc/project_ideas/libdiskfs_locking.mdwn b/community/gsoc/project_ideas/libdiskfs_locking.mdwn
index f26efb7f..faac8bd9 100644
--- a/community/gsoc/project_ideas/libdiskfs_locking.mdwn
+++ b/community/gsoc/project_ideas/libdiskfs_locking.mdwn
@@ -13,12 +13,8 @@ License|/fdl]]."]]"""]]
 
 [[!tag open_issue_hurd]]
 
-Every now and then, new locking issues are discovered in
-[[hurd/libdiskfs]] or [[hurd/translator/ext2fs]], for example.  Nowadays
-these in fact seem to be the most often encountered cause of Hurd crashes
-/ lockups.
-
-One of these could be traced
+Nowadays the most often encountered cause of Hurd crashes seems to be lockups
+in the [[hurd/translator/ext2fs]] server.  One of these could be traced
 recently, and turned out to be a lock inside [[hurd/libdiskfs]] that was taken
 and not released in some cases.  There is reason to believe that there are more
 faulty paths causing these lockups.
diff --git a/community/gsoc/project_ideas/secure_chroot.mdwn b/community/gsoc/project_ideas/secure_chroot.mdwn
index 57739861..bfaf330b 100644
--- a/community/gsoc/project_ideas/secure_chroot.mdwn
+++ b/community/gsoc/project_ideas/secure_chroot.mdwn
@@ -12,7 +12,7 @@ License|/fdl]]."]]"""]]
 [[!meta title="Secure chroot Implementation"]]
 
 As the Hurd attempts to be (almost) fully [[UNIX]]-compatible, it also implements a
-`chroot` [[system call]].  However, the current implementation is not really
+`chroot()` [[system call]].  However, the current implementation is not really
 good, as it allows easily escaping the `chroot`, for example by use of
 [[passive_translators|hurd/translator]].
 
diff --git a/community/gsoc/project_ideas/testing_framework.mdwn b/community/gsoc/project_ideas/testing_framework.mdwn
new file mode 100644
index 00000000..0448bc6b
--- /dev/null
+++ b/community/gsoc/project_ideas/testing_framework.mdwn
@@ -0,0 +1,55 @@
+[[!meta copyright="Copyright © 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="Automated Testing Framework"]]
+
+Hurd development would benefit greatly from automated tests.
+Unit tests should be added for all the major components
+(Mach; Hurd servers and libraries).
+Also, functional tests can be performed on various levels:
+Mach; individual servers; and interaction of several servers.
+
+(The highest level would actually be testing libc functionality,
+which in turn uses the various Hurd mechanisms.
+glibc already comes with a test suite --
+though it might be desirabe to add some extra tests
+for exercising specific aspects of the Hurd...)
+
+Our page on [[automated testing|open_issues/unit_testing]] collects some relevant material.
+
+The Goal of this task is to provide testing frameworks
+that allow automatically running tests
+as part of the Hurd and Mach build processes.
+The student will have to create the necessary infrastrucure,
+and a couple of sample tests employing it.
+Ideally, all the aspects mentioned above should be covered.
+At least some have to be ready for use and upstream merging
+before the end of the summer.
+
+(As a bonus,
+in addition to these explicit tests,
+it would be helpful to integrate some methods
+for testing [[locking validity|open_issues/locking]],
+performing static code analysis etc.)
+
+This task probably requires some previous experience
+with unit testing of C programs,
+as well as dealing with complex build systems.
+No in-depth knowledge about any specific parts of the Hurd should be necessary,
+but some general understanding of the Hurd architecture
+will have to be aquired to complete this project.
+This makes it a very good project
+to get started on Hurd development :-)
+
+Possible mentors: ?
+
+Exercise: Create a program performing some simple test(s) on the Hurd or Mach code.
+It doesn't need to be integrated in the build process yet --
+a standalone progrem with it's own Makefile is fine for now.
diff --git a/community/gsoc/project_ideas/valgrind.mdwn b/community/gsoc/project_ideas/valgrind.mdwn
index 16cd1373..17385f75 100644
--- a/community/gsoc/project_ideas/valgrind.mdwn
+++ b/community/gsoc/project_ideas/valgrind.mdwn
@@ -35,14 +35,14 @@ Compared to Linux,
 [[microkernel/Mach]] (the microkernel used by the Hurd) has very few kernel traps.
 Almost all [[system call]]s are implemented as [[RPC]]s instead --
 either handled by Mach itself, or by the various [[Hurd servers|hurd/translator]].
-All RPCs use a pair of `mach_msg` invocations:
+All RPCs use a pair of `mach_msg()` invocations:
 one to send a request message, and one to receive a reply.
-However, while all RPCs use the same `mach_msg` trap,
+However, while all RPCs use the same `mach_msg()` trap,
 the actual effect of the call varies greatly depending on which RPC is invoked --
-similar to the `ioctl` call on Linux.
+similar to the `ioctl()` call on Linux.
 Each request thus must be handled individually.
 
-Unlike `ioctl`,
+Unlike `ioctl()`,
 the RPC invocations have explicit type information for the parameters though,
 which can be retrieved from the message header.
 By analyzing the parameters of the RPC reply message,