summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorantrik <antrik@users.sf.net>2008-03-17 10:13:10 +0100
committerantrik <antrik@users.sf.net>2008-03-17 10:13:10 +0100
commit91933e80c1ee71840d5246c9b20c234be43d6dbf (patch)
treec24725adcd8bb3782b921acaf10af33f492065e5
parenta1e4641e3aaea496667972e0972091676a9c4df1 (diff)
Removed (link) placeholders -- students will soon start looking at this page, so it should not look like a draft anymore. (Even though it really is...)
-rw-r--r--community/gsoc/project_ideas.mdwn26
1 files changed, 9 insertions, 17 deletions
diff --git a/community/gsoc/project_ideas.mdwn b/community/gsoc/project_ideas.mdwn
index c2921dd5..8d6b6efc 100644
--- a/community/gsoc/project_ideas.mdwn
+++ b/community/gsoc/project_ideas.mdwn
@@ -27,8 +27,6 @@ time for porting more drivers, or implementing a more sophisticated userspace
infrastructure. The latter requires good understanding of the Hurd philosophy,
to come up with an appropriate design.
-(links)
-
* hurdish TCP/IP stack
The Hurd presently uses a TCP/IP stack based on code from an old Linux version.
@@ -50,8 +48,6 @@ layers, it's up to the student to design and implement the various interfaces
at each layer. This task requires understanding the Hurd philosophy and
translator programming, as well as good knowledge of TCP/IP.
-(links)
-
* new driver glue code
Although a driver framework in userspace would be desirable, presently the Hurd
@@ -68,8 +64,6 @@ This is a doable, but pretty involved project. Experience with driver
programming under Linux (or BSD) is a must. (No Hurd-specific knowledge is
required, though.)
-(links)
-
* server overriding mechanism
The main idea of the Hurd is that every user can influence almost all system
@@ -86,7 +80,7 @@ The goal of this project is to provide a simple method for overriding
individual standard servers, using environment variables, or a special
subshell, or something like that.
-Various approaches for such a mechanism has been discussed before. (links)
+Various approaches for such a mechanism has been discussed before.
Probably the easiest (1) would be to modify the Hurd-specific parts of glibc,
which are contacting various standard servers to implement certain system
calls, so that instead of always looking for the servers in default locations,
@@ -133,7 +127,7 @@ the context in which passive translators are exectuted; changing the
interpretation of filenames in a chroot; to reworking the whole passive
translator mechanism. Some involving a completely different approch to chroot
implementation, using a proxy instead of a special system call in the
-filesystem servers. (links)
+filesystem servers.
The task is to pick and implement one approach for fixing chroot.
@@ -304,7 +298,7 @@ The reason for this slowness is lack and/or bad implementation of common
optimisation techniques, like scheduling reads and writes to minimalize head
movement; effective block caching; effective reads/writes to partial blocks;
reading/writing multiple blocks at once. The ext2 filesystem driver might also
-need some optimisation at a higher logical level. (links)
+need some optimisation at a higher logical level.
The goal of this project is to analyze the current situation, and implement/fix
various optimisations, to achieve significantly better disk performance. It
@@ -329,8 +323,6 @@ implementation to other systems, implementing any worthwhile improvements, and
general optimisation/tuning. It requires very good understanding of the Mach
VM, and virtual memory in general.
-(links)
-
* improved NFS implementation
The Hurd has both NFS server and client implementations, which work, but not
@@ -340,7 +332,7 @@ could be owed to the fact that only NFSv2 is supported so far.
This project encompasses implementing NFSv3 support, fixing bugs and
performance problems -- the goal is to have good NFS support. The work done in
-a previous unfinished GSoC project can serve as a starting point. (link)
+a previous unfinished GSoC project can serve as a starting point.
Both client and server parts need work, though the client is probably much more
important for now, and shall be the major focus of this project.
@@ -357,7 +349,7 @@ implemented. This breaks many applications.
The goal is to make all file locking mechanisms work properly. This requires
finding all existing shortcomings (through systematic testing and/or checking
for known issues in the bug tracker and mailing list archives), and fixing
-them. (links)
+them.
This task will require digging into parts of the code to understand how file
locking works on the Hurd. Only general programming skills are required.
@@ -378,7 +370,7 @@ desired constellations.
The goal is to create a set of powerful tools for managing at least one
desirable virtualization scenario. One possible starting point could be the
-subhurd/neighbour Hurd mechanism (link), which allows a second almost totally
+subhurd/neighbour Hurd mechanism, which allows a second almost totally
independant instance of the Hurd in parallel to the main one. The current
implementation has serious limitations though. A subhurd can only be started by
root. There are no communication channels between the subhurd and the main one.
@@ -450,7 +442,7 @@ debugging purposes; but this is highly system-specific anyways, so there is
probably no point in trying to duplicate this functionality as well...)
The existing partially working procfs implementation from the hurdextras
-repository (link) can serve as a starting point, but needs to be largely
+repository can serve as a starting point, but needs to be largely
rewritten. (It should use libnetfs rather than libtrivfs; the data format needs
to change to be more Linux-compatible; and it needs adaptation to newer system
interfaces.)
@@ -547,7 +539,7 @@ translator also would be nice if time permits, but is not mandatory part of the
task.
The existing partial (read-only) xmlfs implementation from the hurdextras
-repository (link) can serve as a starting point.
+repository can serve as a starting point.
This task requires pretty good designing skills. Good knowledge of XML is also
necessary. Learning translator programming will obviously be necessary to
@@ -571,7 +563,7 @@ The Hurd has had such a tmpfs for a long time. However, the existing
implementation doesn't work anymore -- it got broken by changes in other parts
of the Hurd design.
-There are several issues. (links) The most serious known problem seems to be
+There are several issues. The most serious known problem seems to be
that for technical reasons it receives RPCs from two different sources on one
port, and gets mixed up with them. Fixing this is non-trivial, and requires a
good understanding of the involved mechanisms.