summaryrefslogtreecommitdiff
path: root/community/gsoc/project_ideas
diff options
context:
space:
mode:
Diffstat (limited to 'community/gsoc/project_ideas')
-rw-r--r--community/gsoc/project_ideas/libdiskfs_locking.mdwn8
-rw-r--r--community/gsoc/project_ideas/secure_chroot.mdwn2
-rw-r--r--community/gsoc/project_ideas/testing_framework.mdwn55
-rw-r--r--community/gsoc/project_ideas/valgrind.mdwn8
4 files changed, 62 insertions, 11 deletions
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,