From d45f4c7d38b15035b4f4dbf4ef441db9fe8aef2e Mon Sep 17 00:00:00 2001 From: antrik Date: Thu, 20 Mar 2008 14:33:02 +0100 Subject: Use proper headings for individual project ideas --- community/gsoc/project_ideas.mdwn | 48 +++++++++++++++++++-------------------- 1 file 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 -- cgit v1.2.3