summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorantrik <antrik@users.sf.net>2008-03-20 14:33:02 +0100
committerantrik <antrik@users.sf.net>2008-03-20 14:33:02 +0100
commitd45f4c7d38b15035b4f4dbf4ef441db9fe8aef2e (patch)
tree017dce3e08d32b287a88e3a1c4aa4ced874a7673
parent84e03de94fea8d62caa1ac102b7b91d75050ffda (diff)
Use proper headings for individual project ideas
-rw-r--r--community/gsoc/project_ideas.mdwn48
1 files changed, 24 insertions, 24 deletions
diff --git a/community/gsoc/project_ideas.mdwn b/community/gsoc/project_ideas.mdwn
index 64af20c7..c25caf6a 100644
--- a/community/gsoc/project_ideas.mdwn
+++ b/community/gsoc/project_ideas.mdwn
@@ -17,7 +17,7 @@ If you have questions regarding the projects, or if there is more than one that
you are interested in and you are unsure which to choose, don't hesitate to
contact us -- on [[IRC]] or using [[mailing_lists]].
-* Lisp, Python, ... bindings
+## Lisp, Python, ... bindings
The main idea of the Hurd design is giving users the ability to easily
modify/extend the system's functionality. This is done by creating filesystem
@@ -50,7 +50,7 @@ choice, and some example servers to prove that it works well in practice. This
project will require gaining a very good understanding of the various Hurd
interfaces. Skills in designing nice programming interfaces are a must.
-* virtualization using Hurd mechanisms
+## virtualization using Hurd mechanisms
The main idea behind the Hurd design is to allow users to replace almost any
system functionality. Any user can easily create a subenvironment using some
@@ -121,7 +121,7 @@ Completing this project will require gaining a very good understanding of the
Hurd architecture and spirit. Previous experience with other virtualization
solutions would be very helpful.
-* namspace based translator selection
+## namspace based translator selection
The main idea behind the Hurd is to make (almost) all system functionality
user-modifiable. This includes a user-modifiable filesystem: The whole
@@ -181,7 +181,7 @@ programming; but the implementation should not be too hard. Perhaps the hardest
part is finding a convenient, flexible, elegant, hurdish method for mapping the
special extensions to actual translators...
-* fix file locking
+## fix file locking
Over the years, UNIX has aquired a host of different file locking mechanisms.
Some of them work on the Hurd, while others are buggy or only partially
@@ -195,7 +195,7 @@ 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.
-* procfs
+## procfs
Although there is no standard (POSIX or other) for the layout of the /proc
pseudo-filesystem, it turned out a very useful facility in GNU/Linux and other
@@ -222,7 +222,7 @@ of the internals of process management in the Hurd. It should not be too hard
coding-wise; and the task is very nicely defined by the exising Linux /proc
interface -- no design considerations necessary.
-* new driver glue code
+## new driver glue code
Although a driver framework in userspace would be desirable, presently the Hurd
uses kernel drivers in the microkernel, gnumach. (And changing this would be
@@ -238,7 +238,7 @@ 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.)
-* server overriding mechanism
+## server overriding mechanism
The main idea of the Hurd is that every user can influence almost all system
functionality, by running private Hurd servers that replace or proxy the global
@@ -288,7 +288,7 @@ This tasks requires some understanding of the Hurd internals, especially a good
understanding of the file name lookup mechanism. It's probably not too heavy on
the coding side.
-* dtrace support
+## dtrace support
One of the main problems of the current Hurd implementation is very poor
performance. While we have a bunch of ideas what could cause the performance
@@ -312,7 +312,7 @@ in their Mach-based kernel might be helpful here...)
This project requires ability to evaluate possible solutions, and experience
with integrating existing components as well as low-level programming.
-* hurdish TCP/IP stack
+## hurdish TCP/IP stack
The Hurd presently uses a TCP/IP stack based on code from an old Linux version.
This works, but lacks some rather important features (like PPP/PPPoE), and the
@@ -333,7 +333,7 @@ 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.
-* improved NFS implementation
+## improved NFS implementation
The Hurd has both NFS server and client implementations, which work, but not
very well: File locking doesn't work properly (at least in conjuction with a
@@ -350,7 +350,7 @@ important for now, and shall be the major focus of this project.
The task has no special prerequisites besides general programming skills, and
an interest in file systems and network protocols.
-* fix libdiskfs locking issues
+## fix libdiskfs locking issues
Nowadays the most often encountered cause of Hurd crashes seems to be lockups
in the ext2fs server. One of these could be traced recently, and turned out to
@@ -367,7 +367,7 @@ implementing unit checks in other parts of the Hurd codebase...)
This task requires experience with debugging locking issues in multithreaded
applications.
-* convert Hurd servers to pthreads
+## convert Hurd servers to pthreads
The Hurd was originally created at a time when the pthreads standard didn't
exist yet. Thus all Hurd servers and libraries are using the old cthreads
@@ -395,7 +395,7 @@ This project requires relatively little Hurd-specific knowledge. Experience
with multithreaded programming in general and pthreads in particular is
required, though.
-* sound support
+## sound support
The Hurd presently has no sound support. Fixing this requires two steps: One is
to port kernel drivers so we can get access to actual sound hardware. The
@@ -414,7 +414,7 @@ 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.
-* disk I/O performance tuning
+## disk I/O performance tuning
The most obvious reason for the Hurd feeling slow compared to mainstream
systems like GNU/Linux, is very slow harddisk access.
@@ -431,7 +431,7 @@ requires understanding the data flow through the various layers involved in
disk acces on the Hurd (filesystem, pager, driver), and general experience with
optimising complex systems.
-* VM tuning
+## VM tuning
Hurd/Mach presently make very bad use of the available physical memory in the
system. Some of the problems are inherent to the system design (the kernel
@@ -448,7 +448,7 @@ 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.
-* mtab
+## mtab
In traditional monolithic system, the kernel keeps track of all mounts; the
information is available through /proc/mounts (on Linux at least), and in a
@@ -503,7 +503,7 @@ implement both the actual mtab translator, and the necessery interface(s) for
gathering the data. It requires getting a good understanding of the translator
mechanism and Hurd interfaces in general.
-* gnumach code cleanup
+## gnumach code cleanup
Although there are some attempts to move to a more modern microkernel
alltogether, the current Hurd implementation is based on gnumach, which is only
@@ -531,7 +531,7 @@ This task requires good knowledge of C, and experience with working on a large
existing code base. Previous kernel hacking experience is an advantage, but not
really necessary.
-* xmlfs
+## xmlfs
Hurd translators allow presenting underlying data in a different format. This
is a very powerful ability: It allows using standard tools on all kinds of
@@ -569,7 +569,7 @@ This task requires pretty good designing skills. Good knowledge of XML is also
necessary. Learning translator programming will obviously be necessary to
complete the task.
-* allow using unionfs early at boot
+## allow using unionfs early at boot
In UNIX systems, traditionally most software is installed in a common directory
hierachy, where files from various packages live beside each other, grouped by
@@ -601,7 +601,7 @@ Completing this task will require gaining a very good understanding of the Hurd
boot process and other parts of the design. It requires some design skills also
to come up with a working mechanism.
-* fix tmpfs
+## fix tmpfs
In some situations it is desirable to have a file system that is not backed by
actual disk storage, but only by anonymous memory, i.e. lives in the RAM (and
@@ -629,7 +629,7 @@ implementation. It requires digging into some parts of the Hurd, incuding the
pager interface and translator programming. This task probably doesn't require
any design work, only good debugging skills.
-* lexical dot-dot resolution
+## lexical dot-dot resolution
For historical reasons, UNIX filesystems have a real (hard) .. link from each
directory pointing to its parent. However, this is problematic, because the
@@ -650,7 +650,7 @@ to use lexical resolution, and to check that the system is still fully
functional afterwards. This task requires understanding the filename resolution
mechanism. It's probably a relatively easy task.
-* secure chroot implementation
+## 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 good,
@@ -675,7 +675,7 @@ new mechanisms. (Translators.) More important than the acualy code is the
documentation of what he did: He must be able to defend why he chose a certain
approach, and explain why he believes this approach really secure.
-* hurdish package manager for the GNU system
+## hurdish package manager for the GNU system
Most GNU/Linux systems use pretty sophisticated package managers, to ease the
management of installed software. These keep track of all installed files, and
@@ -710,7 +710,7 @@ mechanisms are necessary to handle stuff like dependencies on other packages.
The goal of this task is to create these mechanisms.
-* To create an installer for Debian GNU/Hurd.
+## To create an installer for Debian GNU/Hurd.
The idea is to port the debian installer to the hurd. The following link has some
relevant information http://wiki.debian.org/DebianInstaller/Hurd