From 91933e80c1ee71840d5246c9b20c234be43d6dbf Mon Sep 17 00:00:00 2001 From: antrik Date: Mon, 17 Mar 2008 10:13:10 +0100 Subject: 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...) --- community/gsoc/project_ideas.mdwn | 26 +++++++++----------------- 1 file 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. -- cgit v1.2.3