History -
Diff -
Top of this page -
Last modified Tue Apr 5 00:19:13 CES 2011
Note! Every year Plan 9 has participated in GSoC we've accepted student-submitted projects not from our list, and that's awesome. You are highly encourage to think about how the ideas and capabilities of Plan 9 (or its cousins) could be used to solve some problem you care about and submit a project for that. We are especially fond of things that present their solution in the form of a 9p/styx file server.
The wikifs(4) in both Plan 9 and Inferno understand a very small set of cues when generating HTML. That set can be limiting. Replace it with something better, like Markdown. Markdown engines in C already exist, so the Plan 9 part of this shouldn't be too hard. I'd suggest doing the Inferno version as well, to make it a good summer sized project. Use any remaining time to convert any existing wiki docs that need it.
Our wikifs(4) doesn't currently do any authentication. Our web server and supporting libraries have support for http authentication, but using data stored in the file system directly. It would be nice if web applications could authenticate against a real Plan 9 authentication server. A student submitting a proposal for this should also investigate what's involved in getting wikifs working over https (it shouldn't be much) to ensure passwords are submitted securely.
The NDISulator is a FreeBSD utility which facilitates using device drivers for Windows network cards in FreeBSD. Plan 9 faces the same problems that led the FreeBSD folks to this, most especially vendors who don't release decent information on their parts. Port the NDISulator so that we can use drivers written for Windows within Plan 9. http://people.freebsd.org/~murray/presentations/20050429-msu-freebsd/img36.html http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/config-network-setup.html
Plan 9's C compiler has generated other types of object files in the past; it would be useful if it could generate things Windows understands. This is a major undertaking as windows has a variety of calling conventions and very different register use. However mingw has tools to generate gcc compatible .a libraries which are very similar to 8l ones. linking could initially be done with gld as. It's noteworthy that the Go toolchain, which is derived from kencc (by Ken!), can already do this.
Write a native (non-APE) library for encoding and decoding ASN.1 DER data. This is a useful step towards future LDAP work. This shouldn't be too hard (and there's lots of reference code), but it will involve reading lots of RFCs and testing.
In Plan 9 (and Inferno) networks, you don't need NAT: just import the gateway's network. Sadly, we don't live in a Plan 9-only world. Write what's needed to allow Plan 9 to act as a NAT gateway for other systems. This should be at least mostly (and perhaps entirely) doable in user space.
The cannonical example is accented caps, such as u+0000c2, Â.
Erik has working xapic code that does cluster, flat and physical mode and can handle 1 < n < 255 apics. It's not clear that x2apic is worth it, but most of the fun would be in working out that problem on 24-core machines driving 10gbe. It's also not a very hard problem, since it's mostly a matter of organization.
Similar. Evaluating msi requires doing some careful timing and working out how msi relates to the rest of the system. Can you ditch apic if you go straight for msi interrupts? Is the performance and configuration pain worth it? This is more difficult than x2apic, but promises better payoff.
three projects aimed toward a 64-bit kernel that seem right-sized for a summer. unfortunately, these may be a bit unsatisfying, as they're a small part of a whole.
This work has been done before, but is unavailable. Erik has a draft. This project would be in service of longer-term goals for amd64 support.
Adapt an existing Javascript implementation of Styx/9P to use HTML5 WebSockets -- or implement one from scratch -- and create a 9P file server that provides a simple draw device using keyboard, mouse event handling and either an SVG or a Canvas element for display. Develop a Plan 9 or Inferno client to interact with it.
There are several cases where it would be useful to have a stand-alone software console. The in-kernel console (rightly) doesn't handle interrupts and does only the most basic keyboard processing. Other software, like telnet, implements its own console handling, as does rio. It would be nice to refactor this into a stand-alone file server that handles these functions and could be used by all these functions, or directly on the cga console.
For some, rio represents a barrier to entry--complaints that it is hard to use or ugly have frequently appeared. It would be nice to have an alternative window manager for those people who don't like rio, perhaps something with more traditional title bars, minimize/maximize/close buttons, etc. Rio could serve as a base for this effort if desired, since it already handles the necessary multiplexing and drawing operations.
Libpanel is old and unmaintained, libcontrol doesn't include e.g. a multi-line text entry area, and both look rather outdated. It would be nice to have a widget library including buttons, drop-down menus, multiple-line text entry, radio buttons, scrollbars, etc. The tk library in Inferno does pretty much everything desired.
The Linux kernel.org provides a very rich environment for prototyping linux enhancements. It also uses a well-known SCM (git) which removes one barrier to entry for new users. This project would set up a kernel.org-like entity that uses mercurial, supports forks, and has a well-defined path for inclusion into the base "kernel.org" repo. It would also support a process for regular updates from sources. Finally, all contrib packages would be included, but not integrated into /sys/src (to make pulls from sources viable); rather, they would live in a seperate tree called /contrib (both source and binary). Learning the lessons from kernel.org is strongly encouraged, but implementing this system in a Plan 9-friendly manner is essential.
Ratrace (Plan 9 version of strace) needs a few fixes: allowing users to get both binary and pretty output from programs; allowing users to set the amount of data dumped for read and write; fixing a remaining few races when children fork; and allowing ratrace to trace itself. This is a pretty straightforward project that would allow students to make minimal changes to the kernel and still learn a lot.
One of the environments many people run Plan 9 under is Qemu/KVM -- but the virtio drivers (which are required for high-performance disk or network access) aren't currently supported in mainline Plan 9. The student(s) would get virtio drivers for first the network and then the block device (or perhaps one student for each) working and in a form suitable for acceptance in the mainline Plan 9 kernel against either the tip Qemu or a recent Qemu/KVM distribution (say Ubuntu 10.10). I believe this task is relatively straightforward and requires no special hardware outside of a PC capable of running Qemu. If there was sufficient time the student could work on other virtio drivers (native 9P, console, etc) The student will also be responsible for doing a base-level performance evaluation of virtio drivers versus emulated drivers for some standard operations (disk access, fossil access, venti access, network stream, etc.) The cool thing is, it'd be honest kernel work, and have tangible results we could all use within a month or so of effort.
Look in /n/sources/contrib/rminnich/lguest for some starting points
It is important that the student have Plan 9 experience for this project and know how to compile and run their own kernels.
See also http://bender.eugenics-research.org/doc/plan_9/GSoC/
Eqn has problems generating clean output for brackets and sqrt. This is prevalent especially when using ps2pdf. Track down and fix the errors so eqn | troff output is clean for publishing pdf papers.
Write a 9P server and supporting clients for relevant systems. Suggested areas are:
Write a 9P file server that can be instructed to create a file tree and associate each node with external directories, files or processes. Very roughly, the prototype file tree instructions might look something like:
/ fst/ = /usr/fst/www/ edit/ snarf > /dev/snarf paste < /dev/snarf mouse | fd0rw /dev/mouse
