8 files changed, 22 insertions, 177 deletions
diff --git a/community/gsoc/project_ideas.mdwn b/community/gsoc/project_ideas.mdwn
index ca10c8a2..649e05c1 100644
--- a/community/gsoc/project_ideas.mdwn
+++ b/community/gsoc/project_ideas.mdwn
@@ -1,12 +1,13 @@
-[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2008, 2009, 2010 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]]."]]"""]]
+is included in the section entitled [[GNU Free Documentation
+License|/fdl]]."]]"""]]
 
 We offer a wide range of possible projects to choose from. If you have an idea
 not listed here, we'd love to hear about it!
@@ -81,10 +82,10 @@ See also the list of [Hurd-related X.org project ideas](http://wiki.x.org/wiki/H
 [[!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="open_issues/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]]
+[[!inline pages="open_issues/performance/io_system" show=0 feeds=no actions=yes]]
 [[!inline pages="community/gsoc/project_ideas/vm_tuning" show=0 feeds=no actions=yes]]
 [[!inline pages="community/gsoc/project_ideas/mtab" show=0 feeds=no actions=yes]]
 [[!inline pages="community/gsoc/project_ideas/gnumach_cleanup" show=0 feeds=no actions=yes]]
@@ -105,4 +106,4 @@ See also the list of [Hurd-related X.org project ideas](http://wiki.x.org/wiki/H
 [[!inline pages="community/gsoc/project_ideas/testsuites" 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]]
+[[!inline pages="open_issues/valgrind" show=0 feeds=no actions=yes]]
diff --git a/community/gsoc/project_ideas/disk_io_performance.mdwn b/community/gsoc/project_ideas/disk_io_performance.mdwn
deleted file mode 100644
index b6c857b0..00000000
--- a/community/gsoc/project_ideas/disk_io_performance.mdwn
+++ /dev/null
@@ -1,36 +0,0 @@
-[[!meta copyright="Copyright © 2008, 2009 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="Disk I/O Performance Tuning"]]
-
-The most obvious reason for the Hurd feeling slow compared to mainstream
-systems like GNU/Linux, is very slow hard disk access.
-
-The reason for this slowness is lack and/or bad implementation of common
-optimization techniques, like scheduling reads and writes to minimize head
-movement; effective block caching; effective reads/writes to partial blocks;
-reading/writing multiple blocks at once; and read-ahead.  The
-[[ext2_filesystem_server|hurd/translator/ext2fs]] might also need some
-optimizations at a higher logical level.
-
-The goal of this project is to analyze the current situation, and implement/fix
-various optimizations, to achieve significantly better disk performance. It
-requires understanding the data flow through the various layers involved in
-disk access on the Hurd ([[filesystem|hurd/virtual_file_system]],
-[[pager|hurd/libpager]], driver), and general experience with
-optimizing complex systems.  That said, the killing feature we are definitely
-missing is the read-ahead, and even a very simple implementation would bring
-very big performance speedups.
-
-Possible mentors: Samuel Thibault (youpi)
-
-Exercise: Look through all the code involved in disk I/O, and try something
-easy to improve. It's quite likely though that you will find nothing obvious --
-in this case, please contact us about a different exercise task.
diff --git a/community/gsoc/project_ideas/language_bindings.mdwn b/community/gsoc/project_ideas/language_bindings.mdwn
index 460b380b..c8a02390 100644
--- a/community/gsoc/project_ideas/language_bindings.mdwn
+++ b/community/gsoc/project_ideas/language_bindings.mdwn
@@ -20,7 +20,7 @@ However, in practice this is not as easy as it should, because creating
 translators and other servers is quite involved -- the interfaces for doing
 that are not exactly simple, and available only for C programs. Being able to
 easily create simple translators in RAD languages is highly desirable, to
-really be able to reap the advantages of the Hurd architecture.
+really be able to reap the [[advantages]] of the Hurd architecture.
 
 Originally Lisp was meant to be the second system language besides C in the GNU
 system; but that doesn't mean we are bound to Lisp. Bindings for any popular
diff --git a/community/gsoc/project_ideas/libcap.mdwn b/community/gsoc/project_ideas/libcap.mdwn
index 1346203d..18c49c48 100644
--- a/community/gsoc/project_ideas/libcap.mdwn
+++ b/community/gsoc/project_ideas/libcap.mdwn
@@ -1,12 +1,12 @@
-[[!meta copyright="Copyright © 2009 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2009, 2010 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]]."]]"""]]
+is included in the section entitled [[GNU Free Documentation
+License|/fdl]]."]]"""]]
 
 [[!meta title="Implementing libcap"]]
 
@@ -33,7 +33,7 @@ probably doable without previous experience with either, though.
 
 David Hedberg applied for this project in 2010,
 and though he didn't go through with it,
-he fleshed out many [[libcap/details]].
+he fleshed out many [[details]].
 
 Possible mentors: Samuel Thibault (youpi)
 
diff --git a/community/gsoc/project_ideas/libcap/details.mdwn b/community/gsoc/project_ideas/libcap/details.mdwn
index aa27a84e..85695978 100644
--- a/community/gsoc/project_ideas/libcap/details.mdwn
+++ b/community/gsoc/project_ideas/libcap/details.mdwn
@@ -5,8 +5,8 @@ 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]]."]]"""]]
+is included in the section entitled [[GNU Free Documentation
+License|/fdl]]."]]"""]]
 
 [[!meta title="Details on implementing libcap"]]
 
@@ -59,7 +59,7 @@ Each process has a three bit fields representing each of the three
 sets (P, E and I).  Each bit field is currently built up of two (32
 bit) integers to be able to hold the 33 currently defined capabilities
 (see linux/capability.h).  Each process further has a bounding set which
-bounds the permitted set.  Two syscalls handles the setting and getting
+bounds the permitted set.  Two [[system call]]s handles the setting and getting
 of capabilities; *capset* and *capget*.  Some related functionality
 can also be controlled by calling *prctl*: the right to read/drop the
 bounding capabilities (PR_CAPBSET_READ/PR_CAPBSET_DROP) and whether
@@ -428,7 +428,7 @@ the following (also detailed somewhat in the same article):
 
 * Execute process as root (or setuid) to gain all capabilities.
 
-* Use the prctl system call to enable keepcaps for the process
+* Use the prctl [[system call]] to enable keepcaps for the process
   (same(?) effect as enabling SECURE_NO_SETUID_FIXUP for the process).
   keepcaps should be off by default.
 
diff --git a/community/gsoc/project_ideas/libdiskfs_locking.mdwn b/community/gsoc/project_ideas/libdiskfs_locking.mdwn
deleted file mode 100644
index 0618bbe6..00000000
--- a/community/gsoc/project_ideas/libdiskfs_locking.mdwn
+++ /dev/null
@@ -1,41 +0,0 @@
-[[!meta copyright="Copyright © 2008, 2009, 2010 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="Fix libdiskfs Locking Issues"]]
-
-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.
-
-The task is systematically checking the [[hurd/libdiskfs]] code for this kind of locking
-issues. To achieve this, some kind of test harness has to be implemented: For
-example instrumenting the code to check locking correctness constantly at
-runtime. Or implementing a unit testing framework that explicitly checks
-locking in various code paths. (The latter could serve as a template for
-implementing unit checks in other parts of the Hurd codebase...)
-
-(A systematic code review would probably suffice to find the existing locking
-issues; but it wouldn't document the work in terms of actual code produced, and
-thus it's not suitable for a GSoC project...)
-
-[Linux' *sparse*](https://sparse.wiki.kernel.org/) could be worth looking at.
-
-This task requires experience with debugging locking issues in multithreaded
-applications.
-
-Possible mentors: Samuel Thibault (youpi)
-
-Exercise: If you could actually track down and fix one of the existing locking
-errors before the end of the application process, that would be excellent. This
-might be rather tough though, so probably you need to talk to us about an
-alternative exercise task...
diff --git a/community/gsoc/project_ideas/secure_chroot.mdwn b/community/gsoc/project_ideas/secure_chroot.mdwn
index feb30a7c..57739861 100644
--- a/community/gsoc/project_ideas/secure_chroot.mdwn
+++ b/community/gsoc/project_ideas/secure_chroot.mdwn
@@ -1,17 +1,18 @@
-[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2008, 2009, 2010 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]]."]]"""]]
+is included in the section entitled [[GNU Free Documentation
+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]].
 
@@ -20,7 +21,7 @@ workaround changing the behavior of passive translators in a `chroot`;
 changing the context in which passive translators are executed; changing the
 interpretation of filenames in a chroot; to reworking the whole passive
 translator mechanism.  Some involving a completely different approach to
-`chroot` implementation, using a proxy instead of a special system call in the
+`chroot` implementation, using a proxy instead of a special [[system call]] in the
 filesystem servers.
 
 See <http://tri-ceps.blogspot.com/2007/07/theory-of-filesystem-relativity.html>
diff --git a/community/gsoc/project_ideas/valgrind.mdwn b/community/gsoc/project_ideas/valgrind.mdwn
deleted file mode 100644
index c6fc7459..00000000
--- a/community/gsoc/project_ideas/valgrind.mdwn
+++ /dev/null
@@ -1,80 +0,0 @@
-[[!meta copyright="Copyright © 2009, 2010 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="Porting Valgrind to the Hurd"]]
-
-[Valgrind](http://valgrind.org/) is an extremely useful debugging tool for memory errors.
-(And some other kinds of hard-to-find errors too.)
-Aside from being useful for program development in general,
-a Hurd port will help finding out why certain programs segfault on the Hurd,
-although they work on Linux.
-Even more importantly, it will help finding bugs in the Hurd servers themselfs.
-
-To keep track of memory use,
-Valgrind however needs to know how each system call affects the validity of memory regions.
-This knowledge is highly kernel-specific,
-and thus Valgrind needs to be explicitely ported for every system.
-
-Such a port involves two major steps:
-making Valgrind understand how kernel traps work in general on the system in question;
-and how all the individual kernel calls affect memory.
-The latter step is where most of the work is,
-as the behaviour of each single system call needs to be described.
-
-Compared to Linux,
-Mach (the microkernel used by the Hurd) has very few kernel traps.
-Almost all system calls are implemented as RPCs instead --
-either handled by Mach itself, or by the various Hurd servers.
-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,
-the actual effect of the call varies greatly depending on which RPC is invoked --
-similar to the ioctl() call on Linux.
-Each request thus must be handled individually.
-
-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,
-Valgrind can know exactly which memory regions are affected by that call,
-even without specific knowledge of the RPC in question.
-Thus implementing a general parser for the reply messages
-will already give Valgrind a fairly good approximation of memory validity --
-without having to specify the exact semantic of each RPC by hand.
-
-While this should make Valgrind quite usable on the Hurd already, it's not perfect:
-some RPCs might return a buffer that is only partially filled with valid data;
-or some reply parameters might be optional,
-and only contain valid data under certain conditions.
-Such specific semantics can't be deduced from the message headers alone.
-Thus for a complete port,
-it will still be necessary to go through the list of all known RPCs,
-and implement special handling in Valgrind for those RPCs that need it.
-
-The goal of this task is at minimum to make Valgrind grok Mach traps,
-and to implement the generic RPC handler.
-Ideally, specific handling for RPCs needing it should also be implemented.
-
-Completing this project will require digging into Valgrind's handling of system calls,
-and into Hurd RPCs.
-It is not an easy task, but a fairly predictable one --
-there shouldn't be any unexpected difficulties,
-and no major design work is necessary.
-It doesn't require any specific previous knowledge:
-only good programming skills in general.
-On the other hand,
-the student will obtain a good understanding of Hurd RPCs while working on this task,
-and thus perfect qualifications for Hurd development in general :-)
-
-Possible mentors: Samuel Thibault (youpi)
-
-Exercise: As a starter,
-students can try to teach valgrind a couple of Linux ioctls,
-as this will make them learn how to use the read/write primitives of valgrind.