gsoc/project_ideas: Restore all project ideas here

While there is certainly some overlap with other areas, it is *not*
acceptable to drop mentors and exercises from GSoC tasks, nor to add
random crap, nor do any other changes that make them less useful as GSoC
tasks -- and this is *not* obvious if they do not live in the
project_ideas namespace. It's also confusing in general.

I tried to preserve all valid changes to the task descriptions themself
-- though I might have messed up some things.

I did leave the now redundant entries in open_tasks in place. Not sure
how to deal with them. As the content is virtually identical anyways,
they probably should be just turned into stubs pointing here. Or don't
list them explicitely at all -- we point out in other places that GSoC
ideas are useful in other contexts too...

For the future, please refrain from reorganising things here without
prior discussion.

1 files changed, 47 insertions, 0 deletions

diff --git a/community/gsoc/project_ideas/libdiskfs_locking.mdwn b/community/gsoc/project_ideas/libdiskfs_locking.mdwn
new file mode 100644
index 00000000..0e38b6a0
--- /dev/null
+++ b/community/gsoc/project_ideas/libdiskfs_locking.mdwn
@@ -0,0 +1,47 @@
+[[!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
+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"]]
+
+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
+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 tests in other parts of the Hurd codebase...)
+
+(A [[systematic code review|security]] 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...)
+
+This task requires experience with debugging locking issues in
+[[multithreaded|multithreading]] applications.
+
+Tools have been written for automated [[code analysis]]; these can help to
+locate and fix such errors.
+
+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...