path: root/community/gsoc/project_ideas/libdiskfs_locking.mdwn
diff options
Diffstat (limited to 'community/gsoc/project_ideas/libdiskfs_locking.mdwn')
1 files changed, 0 insertions, 41 deletions
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,
-[[!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*]( could be worth looking at.
-This task requires experience with debugging locking issues in multithreaded
-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...