diff options
| -rw-r--r-- | community/gsoc/project_ideas.mdwn | 199 |
1 files changed, 199 insertions, 0 deletions
diff --git a/community/gsoc/project_ideas.mdwn b/community/gsoc/project_ideas.mdwn new file mode 100644 index 00000000..b789eabb --- /dev/null +++ b/community/gsoc/project_ideas.mdwn @@ -0,0 +1,199 @@ +[[meta copyright="Copyright © 2008 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]]."]]"""]] + +* translator stacking mechanism + +One of the major strengths of the Hurd design is that not only it uses a +modular (multiserver) architecture internally, but also encourages a similar +modular architecture at application level. Complex applications can be created +intuitively from simple components by combining them through translator +stacking -- similar to traditional UNIX pipes, but much more suitable for +complex interaction and structured data. + +The downside is that communication between the components with filesystem- or +other RPC interfaces imposes a relatively high overhead: Not only are the +actual IPC operations relatively slow in Mach, but also communication is +generally more complicated because of the constraints of an RPC interface. + +In some cases, like network stacks for example, the overhead might prove a +serious problem; a mechanism that allows cutting down on it by more or less +transparently, taking a shortcut in certain situations to avoid actual RPC, is +highly desirable. + +The work on libchannel as a special-purpose translator stacking mechanism as +last year's GSoC project yielded some very interesting ideas for a more generic +translator stacking framework. + +(links) + +The task here is to follow up on the previous work, creating a framework based +on these ideas, and implementing or porting some translators based on this +framework to prove it's applicability in practice. It is up to the student to +decide whether it's better to start with the previous libchannel code, turning +it into something more generic; or starting from scratch, using libchannel (and +libstore) only for reference. + +This task is pretty involved. The architecture of the stacking framework has +been discussed before; but the student needs to design the various actual +interfaces for the framework, and implement all of them. + +* 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 +second is to implement a userspace server (translator), that implements an +interface on top of the kernel device that can be used by applications -- +probably OSS or maybe ALSA. + +Completing this task requires porting at least one driver (e.g. from Linux) for +a popular piece of sound hardware, and the basic userspace server. For the +driver part, previous experience with programming kernel drivers is strongly +advisable. The userspace part requires some knowledge about programming Hurd +translators, but shouldn't be too hard. + +Once the basic support is working, it's up to the student to use the remaining +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. +This works, but lacks some rather important features (like PPP/PPPoE), and the +design is not hurdish at all. + +A true hurdish network stack will use a set of stack of translator processes, +each implementing a different protocol layer. This way not only the +implementation gets more modular, but also the network stack can be used way +more flexibly. Rather than just having the standard socket interface, plus some +lower-level hooks for special needs, there are explicit (perhaps +filesystem-based) interfaces at all the individual levels; special application +can just directly access the desired layer. All kinds of packet filtering, +routing, tunneling etc. can be easily achieved by stacking compononts in the +desired constellation. + +While the general architecture is pretty much given by the various network +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 +uses kernel drivers in the microkernel, gnumach. (And changing this would be +far beyond a GSoC project...) + +The problem is that the drivers in gnumach are presently old Linux drivers +(mostly from 2.0.x) accessed through a glue code layer. This is not an ideal +solution, but works quite OK, except that the drivers are very old. The goal of +this project is to redo the glue code, so we can use drivers from current Linux +versions, or from one of the free BSD variants. + +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 +functionality, by running private Hurd servers that replace or proxy the global +default implementations. + +However, running such a cumstomized subenvironment presently is not easy, +because there is no standard mechanism to easily replace an individual standard +server, keeping everything else. (Presently there is only the subhurd method, +which creates a completely new system instance with a completely independant +set of servers.) + +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) +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, +they first check for overrides in environment variables, and use these instead +if present. + +A somewhat more generic solution (2) could use some mechanism for arbitrary +client-side namespace overrides. The client-side part of the filename lookup +mechanism would have to check an override table on each lookup, and apply the +desired replacement whenever a match is found. + +Another approach would be server-side overrides. Again there are various +variants. The actual servers themself could provide a mechanism to redirect to +other servers on request. (3) Or we could use some more generic server-side +namespace overrides: Either all filesystem servers could provide a mechanism to +modify the namespace they export to certain clients (4), or proxies could be +used that mirror the default namespace but override certain locations. (5) + +Variants (4) and (5) are the most powerful. They are intimately related to +chroots: (4) is like the current chroot implementation works in the Hurd, and +(5) has been proposed as an alternative. The generic overriding mechanism could +be implemented on top of chroot, or chroot could be implemented on top of the +generic overriding mechanism. But this is out of scope for this project... + +In practice, probably a mix of the different approaches would prove most useful +for various servers and use cases. It is strongly recommended that the student +starts with (1) as the simplest approach, perhaps augmenting it with (3) for +certain servers that don't work with (1) because of indirect invocation. + +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. + +* 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, +as it allows easily escaping the chroot, for example by use of passive +translators. + +Many solutions have been suggested for this problem -- ranging from simple +workaround changing the behaviour of passive translators in a chroot; changing +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) + +The task is to pick and implement one approach for fixing chroot. + +This task is pretty heavy: It requires a very good understanding of file name +lookup and the translator mechanism, as well as of security concerns in general +-- the student must prove that he really understands security implications of +the UNIX namespace approach, and how they are affected by the introduction of +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. + +* lexical dot-dot resolution +* namspace based translator selection +* gnumach code cleanup +* fix libdiskfs locking issues +* dtrace support +* I/O performance tuning +* VM performance tuning +* improved NFS implementation +* fix file locking +* virtualization based on Hurd mechanisms +* procfs +* mtab +* xmlfs +* fix tmpfs +* allow using unionfs early at boot +* hurdish package manager |