summaryrefslogtreecommitdiff
path: root/community/gsoc/project_ideas/libdiskfs_locking.mdwn
diff options
context:
space:
mode:
authorThomas Schwinge <thomas@schwinge.name>2011-03-26 01:29:05 +0100
committerThomas Schwinge <thomas@schwinge.name>2011-03-26 01:29:05 +0100
commit2ad64644b9290ed1b63108b01ef63939adba5a93 (patch)
treeffcd63c76d4dc0ecd008f404ce01916c13377f3b /community/gsoc/project_ideas/libdiskfs_locking.mdwn
parent09cf968b288adad78fcd2717db5643b5b9644b84 (diff)
Re-integrate GSoC pages with the non-GSoC world.
Remove duplicates, apart from procfs, which should rather be removed from the GSoC items.
Diffstat (limited to 'community/gsoc/project_ideas/libdiskfs_locking.mdwn')
-rw-r--r--community/gsoc/project_ideas/libdiskfs_locking.mdwn10
1 files changed, 6 insertions, 4 deletions
diff --git a/community/gsoc/project_ideas/libdiskfs_locking.mdwn b/community/gsoc/project_ideas/libdiskfs_locking.mdwn
index 0e38b6a0..f26efb7f 100644
--- a/community/gsoc/project_ideas/libdiskfs_locking.mdwn
+++ b/community/gsoc/project_ideas/libdiskfs_locking.mdwn
@@ -11,6 +11,8 @@ License|/fdl]]."]]"""]]
[[!meta title="Fix libdiskfs Locking Issues"]]
+[[!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
@@ -24,19 +26,19 @@ 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
+runtime. Or implementing a [[open_issues/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
+(A [[systematic code review|open_issues/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.
+[[multithreaded|open_issues/multithreading]] applications.
-Tools have been written for automated [[code analysis]]; these can help to
+Tools have been written for automated [[open_issues/code_analysis]]; these can help to
locate and fix such errors.
Possible mentors: Samuel Thibault (youpi)