History -
Diff -
Top of this page -
Last modified Fri Mar 29 20:33:46 CET 2013
Note! We actively encourage students to submit applications for projects not on this list, too. We've accepted such projects three out of four years we've participated. Plan 9 (and its cousins) embody a different way of approaching problems, and we get most excited when we see a student (or anyone, for that matter) apply those ideas to their own set of problems.
In addition to this ideas page, prospective students should look over our GSoC Student Expectations and be prepared to submit an application matching our GSoC Student Application. For more information, note our general GSoC page.
If you're looking for additional ideas, you might check out the todo, bugs, and ideas lists for Inferno, 9atom, and Acme-SAC. These lists are more general and will not all be a good size for a summer, but are good sources of inspiration. Some of the most promising fits are duplicated below.
If you're a community member and you have an idea you'd be willing to act as mentor for, please add it to this page! Just follow the format given and provide a good summary of the project. If you'd like, create and link a wiki page with as much detail as you'd like (but please don't swamp this page). Please only add ideas you're willing to mentor (or have directly spoken to whoever you're marking down as mentor).
Several of these ideas have the title linked to a page containing more information on the project.
Ideas related to Plan 9's graphics systems, including kernel devices, window systems, and supporting libraries.
Implement the draw device capabilities -- draw(3) -- in HTML5 (Javascript), using Canvas graphics primitives and export the draw hierarchy via 9P using the Websocket API. The client side can be implemented relatively easily on Plan 9 using Go language and the http and net/websocket packages and import(4). This has a potential of becoming a universal GUI capability for Go language as well. This is similar in approach to noVNC, but should be easier to implement. The implementation can be simplified using either Dart (dart2js) or Java (GWT), rather than using Javascript.
The Plan 9 windowing system is quite different from X11. Rendering is handled by the kernel graphics driver itself, with a user-mode application responsible for window management issues like placement, sizing, labels, and visability. Today, the only such program is rio(1). It would be fun to have a few alternatives. Design and implement an alternative interface. Some popular ideas include tiling interfaces (similar to acme(1) or X11's wmii or dwm), exploring keyboard-driven control, or touch-based interaction.
A student looking to work on a project in this area should be familiar with Plan 9's existing windowing system, including rio(1) and draw(3), at a minimum. It would be good to also review some of the rio hacks found in the contrib index.
Project ideas related to the kernel, the various ports, or driver support. Note that we're always interested in ports to new hardware, provided you can ensure that you and your mentors have the same device. Pick anything and get Plan 9 working on it!
Linux includes a utility called lockdep which has been very helpful for them in identifying and eliminating hard lockups caused by improperly managed locks. A similar tool could be useful for Plan 9. This is an ambitious project, likely best suited to a graduate-level student already familiar with the Plan 9 kernel internals.
The Plan 9 kernel for ARM runs on systems with both 7500-style and the newer vfp floating point instructions. The kernel includes an emulator for the 7500-style instructions, as well. Unfortunately, this means that in mixed environments you can only safely assume 7500-style floating point. It would be nice to replace that emulator with one which handles vfp, so we can safely generate those instructions by default.
We have a port of Plan 9 to the Raspberry Pi which has proven very popular. The port is stable and performs well, but there is more work to be done. We could certainly use drivers for I²C, I²S, audio, gpio, pwm, and spi. If you have compatible hardware, it might be neat to take a look at the DSI or CSI-2 connectors (although note that hardware for those is not common, and for hardware projects you must ensure you and your mentor have the same kit). Oh, and those LEDs! Put together a proposal for a set of drivers you'd be interested in working on and a sample application.
Project ideas related to the web, either in Plan 9 tools providing web services or in ways to interact with Plan 9 systems.
OAuth is a very common method for users to provide authorization to web services. To facilitate writing Plan 9 and Inferno clients for many of these services, it would be nice to teach factotum(4) how to speak OAuth. There are some design considerations that need to be thought through; the models don't map directly. Add OAuth to either the Plan 9 or Inferno factotums and write an example client.
While it isn't OAuth, flickrfs has support for Flickr's pre-OAuth authentication method, which has some similarities. Interested students might look to it for reference or inspiration.
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 html generated by man2html (and related tools, like ms2html(1)) is serviceable but basic and outdated. Take a look at the output and suggest a set of enhancements. Ideas include optional use of style sheets and handling of preprocessors like pic(1) and tbl(1). The difficulty of this project will depend on the scope of your specific proposal.
Project ideas related to compilers, development tools, or supporting libraries.
The LXR project has created some very useful tools for cross-referencing different source trees. This idea has been productively expanded by FXR to compare across operationg systems (FXR includes various BSDs, Linuxes, and an old Plan 9 tree). As Plan 9 evolves, it would be very useful to tree maintainers to have an easy way to find, track, and explore differences between trees. This project would be to provide tools to scan different source trees (the Bell Labs tree, 9atom, NIX, NxM, 9front, possibly Inferno and Plan 9 from User Space) and allow users to see specific changes, perhaps including changes over time. Your proposal should describe the interface you're thinking about providing (file server? web application?), what you think some of the important issues are, and clearly define the scope of work (for example, will you be doing multi-way diffs, or just 1-to-1 comparisons?). Multiple Plan 9 sites would be happy to host the results of this work.
Ideas for applications; user-mode code in an existing environment.
rtl-sdr is a C library that enables using the Realtek RTL2832U based DVB-T receivers as Software Defined Radio receivers (SDR). These inexpensive USB dongles ($20-$30) have been used as receivers for a variety of signaling systems and frequencies including ADS-B, GPS and GSM. Typically additional signal processing is performed by GnuRadio on data captured by rtl-sdr library. The main porting activity will involve replacing the calls to LibUSB with an interface to Plan 9's usb server.
When booting off the network, the bootloader often does dhcp to discover various network information. The lease given is discarded once the kernel is running, and the kernel (typically) runs DHCP over again itself, just to get the same information back. Teach pcipl (one of the new generation of Plan 9 bootladers) to pass the lease to the kernel (and teach the kernel how to accept it, of course). This can make a difference on moderately-sized networks where the spanning tree might take some time to run.
It would be nice for Plan 9 to be able to speak Bonjour. When in heterogeneous networks, there are various services that Plan 9 cannot serve without being able to do so. Get the protocol working and integrate it with Plan 9's existing ndb/cs infrastructure.
Plan 9's new ssh2 implementation does not currently implement the keyboard-interactive authentication method. There are lots of systems where this would be very useful. Add it. This is almost certainly not a summer-sized project on its own, but could be a good addition to other projects, especially if you're already working on ssh, factotum, or authentication.
Plan 9 and Inferno represent services and resources as directories of file-like names, that can be opened, read and written to use the service. A single file service protocol, 9P, is used to implement and access those services. Write the client-side implementation of 9P in Dart, to allow applications in web browsers to access network resources and services that are represented using 9P. The package should allow concurrent use of the connection, multiplexing access to files within several remote name spaces (mount points). 9P is also implemented by Linux (as *v9fs*), which further extends the reach of this package.
Project ideas that don't fit into - or span multiple of - the above catagories.
This involves both development tools and web ideas. Limbo programs are currently compiled into a simple portable, concurrent, memory-memory machine language called Dis. It is then either interpreted or compiled-on-the-fly into target machine code. I'd quite like to write simple Limbo programs that will run in any web browser. Dart is a language from Google, similar to C# or Java, which runs in web browsers, one way or another.
Starting with the existing Dis interpreter as a model, roughly 4,300 lines of C, write a Dis interpreter in Dart that will load and run a non-trivial subset of Dis. It should include Dis processes, which will be multiplexed within the interpreter, much as in the current interpreter. It should include the current Sys module, or a large subset, but is unlikely to include Draw.
The advantage of Dart over (say) raw JavaScript is that most people familiar with Java and especially C# ("Java with the bugs fixed") should be able to pick up Dart quickly, and Dart already has an extensive library of interfaces into the underlying web browser and network, which might be useful. Another notation that compiles into JavaScript could be used instead.
