History -
Diff -
Top of this page -
Last modified Fri Mar 29 18:28:06 CET 2013
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.
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.
There is a separate list of Inferno-related project ideas on their site. Many may be larger than is suitable for GSoC, but they might prove useful ideas. The ones that seem most suitable have been included below.
Ideas related to Plan 9's graphics systems, including kernel devices, window systems, and supporting libraries.
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.
A related but different approach would be to see how multi-touch capable devices could work with the Plan 9 windowing systems. From a previous GSoC we have a drawterm(8) implementation that runs on iOS devices (it could use some refreshing), and more recent work has given Plan9port on OS X some multi-touch recognition. Still, these aren't a perfect fit for rio(1) and acme(1) as they exist today.
In either case, a student looking to work on these projects should be familiar with the existing Plan 9 windowing systems.
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 cannonical example is accented caps, such as u+0000c2, Â.
This would involve creating an analogue to stringwidth(2), stringheight(2), and using the result in the frame(2) library.
There are a few plan 9 programs like gmap(1) and radar(1) that would benefit from a panning viewer. The image-generating programs should provide the panner enough information to generate adjacent images without any private knowledge.
Almost no truetype fonts provide good Unicode coverage and good quality. Ttf2subf is a Plan 9 Ports program for turning ttf files into plan 9 fonts. Since a single subfont in plan 9 has a limited size, ttf2subf tries to create the minimal set of subfonts possible for the given ttf. This results in subfonts that cross Unicode block boundaries. If ttf2subf instead broke fonts at block boundaries, similar fonts could be mixed according to quality and coverage.
Give hosted Inferno a basic interface to OpenGL or OpenVG on a Linux or MacOS host. "Basic" means a small subset of OpenGL or OpenVG, to test ideas and keep the project manageable. Ideally, unlike most OpenGL interfaces, this one would use novelties such as data structures. It could be either a module interface, or a name space, or a module interface to a name space (in the style of draw(2)). For GSoC, best to keep it small and basic, but enough to draw some interesting or amusing things.
This suggestion came from the Inferno ideas page.
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!
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
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.
Plan 9 currently has no access to pci extended configuration space. Wikipedia has a good overview of what extended configuration space is. The goal would be to make extended-space access possible on as many machines as possible.
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/
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. The implementation needs to support the TCP mss hack, and ftp. This can be implemented in user space. If performance is an issue, it should be easy to move into the kernel if the student has completed the work.
Project ideas related to the web, either in Plan 9 tools providing web services or in ways to interact with Plan 9 systems.
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.
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.
Modify one of the Inferno httpd implementations to allow a process (or a set of processes) to maintain state for a logical http session, so the server-side application is written as a (fairly) normal process. Write some useful applications.
Originally from the Inferno Idas page.
The Inferno fork Acme-sac has a version of the web browser Charon which provides a text-only interface via acme(4). For users who already run acme under Plan 9 or Plan 9 from User Space, it is frustrating to have that separate. Make the text-only charon interface work by importing the acme(4) file system from Plan 9 or Plan 9 from User Space. Some extensions to the target acme may be needed.
Project ideas related to compilers, development tools, or supporting libraries.
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.
From the Inferno Ideas page:
/appl/lib/crypt/ssl3.b has an implementation of SSL3(TLS), /appl/lib/crypt/sslsession.b implements some form of SSL session cache, and /*/port/devtls.c has support for the record structure and control operations of SSL3 (but ssl3.b doesn't use it). Check ssl3.b etc. against the specification, and change it to suit. You might also need to change x509.b. (GW)
Ideas for applications; user-mode code in an existing environment.
Plan 9 currently implements an older version of tls. Bring this up-to-date with the current standards. This project will likely not require as much code as reading of standards.
Create file servers in (Plan 9 or Inferno) or modules (in Inferno) to give access to some of the more interesting Google APIs, where "more interesting" means you also write a useful and/or amusing application that uses the API(s) just implemnted.
Originally from the Inferno Ideas page, also applicable to Plan 9.
Create file servers (in Plan 9 or Inferno) or modules (in Inferno) to give access to the Amazon Web Services APIs, and write a useful and/or amusing application that uses them.
Originally from the Inferno Ideas page, also applicable to Plan 9.
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
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.
Project ideas that don't fit into - or span multiple of - the above catagories.
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.
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:
