Project ideas for the 2009 Google Summer of Code

Working list of ideas for Google Summer of Code 2009 projects for Plan 9 and related projects (in alphabetical order). I’ve attempted to place a difficulty rating by each project. Since there’s always contention between what people actually feel is useful, I’ve omitted that from this page.

9term Alternative

From Sape: An alternative 9term (A-term) that implements most of the features of acme. Think of an Aterm as one of the windows in sam, or one of the tiles in acme. Allow an application to run in an Aterm just like it can now run in a 9term. If it doesn’t use graphics (e.g., a shell, or the “display of a file”), editing is allowed, as in acme. The display-file program just happens to have a command to do Put. It’d be easy to make it work in Plan9 from user space as well as native Plan 9.

Acme “Content Assist”

From Caerwyn: “I’d like Acme to have some kind of content assist. A first step is to make file completion more useful so that it is easier to complete a filename from a list than the current method of using the mouse. The next step would be content assist for a specific language like python. It should be possible to ctrl-space at a point in the text editor and get a completion list in another window. It should be possible to use the keyboard to navigate completions using the keyboard or select a match using a single click from the mouse. I’d consider info-popups (as in eclipse, or IDLE) outside the normal acme text window manager a possibility. But integration with and possible extension of acme fs a first target.

“Another acme related project is syntax highlighting. One possible approach is to adapt the frame.b module to use tags similar to the tk text module, to tag slices of text with font coloring. A first step is to highlight all matches to a regular expression.”

Acme interface for acid

Acme could use a good interface for the acid debugger. Ideally, it would contain some useful libraries for performing tasks in acid (similar perhaps to some of the ones that GDB provides). The student would also create a set of workthrough tutorials to bring someone up to speed with acid. Caerwyn’s adeb may be a good starting point.

ACPI support

ACPI support is becoming increasingly important for modern PC systems. Plan 9 has gotten good distance out of not touching it, but this is getting more challenging. In addition to features like advanced power management, ACPI support is becoming more important for basic system function, as board vendors increasingly ship parts with incorrect PIR or MP tables (among other things), where the information is correct in ACPI. This would be kernel-level (and perhaps boot loader) work to make ACPI on supported boards available to the system; heavy C, perhaps some assembler. A GSoC project would likely not finish this, but at least give us a very good push forward.

Firewalling / Packet filtering in Plan 9

Plan 9 currently has minimal support for packet filtering and classification, and no support for NAT. This makes Plan 9 very difficult to use in edge of network situations in general heterogeneous environments. This project would implement a basic layer 3 filter, potentially with some stateful filtering support, and NAT. Devon has already done work in this area and would be a good candidate to mentor.

GCC Port

Plan 9 could benefit heavily from a GCC port. Lucio has some ongoing work on this, and there are two directions for development: porting Plan 9 libraries to NetBSD / Ubuntu for cross-compilation, and getting ELF support in Plan 9.

General 9vx Improvements

There are many, many projects for which 9vx is useful. Unfortunately, it has a couple of shortcomings that prevent it from being generally usable in several instances, including honoring filesystem permissions, doing native networking, running on 64-bit systems other than Linux, and various other tasks. While there is some code supporting native networking, it’s not very extensible, nor is it solid. Improving 9vx to look / act / feel more like Plan 9 both from the outside and from the inside would be a great thing.

Gitfs / SCMfs

From the first file server, Plan 9 has a strong history of representing revisions over time as a regular file tree. The recommended system continues this today with daily archival dumps of the full file system. Conceptually, this matches well with many revision control systems. Implement a user-mode file system to present revisions, branches, and so on in a git repository as a file tree. The most likely implementation language is C or Limbo, but doing it in another language with a 9P implementation may be interesting, as well. It may be useful to plan this as a generic SCM filesystem with an initial git plugin, for the ability to support more SCMs down the road.

Glendix

Glendix is a related project to Plan 9, trying to import as many of the benefits of Plan 9 as possible to Linux. Their objective is to be able to replace the normal GNU-based userland of a Linux system with the Plan 9 userland. If you really like our ideas but are looking for something more linux-focused, check out their ideas page (and organization generally). The Plan 9 GSoC effort will be entertaining proposals for Glendix-based projets, and encourage students interested in Glendix to apply with us.

Inferno Host OS device support

Inferno can run on top of an existing OS, and gets access to the resources of the underlying system. Currently, support for “odd” devices - video cameras, pen/tablet input, 3D mice, &c, is poor. Implement Inferno kernel modules (in C) to expose these host OS devices within Inferno.

Improving user-level fileserver performance

User level fileservers will never perform as well as they would in-kernel, but there are certainly many improvements that could be made to increase their responsiveness. This would likely require using devtrace and / or implementing some additional performance counters.

Inferno / Eclipse IDE Integration

From Caerwyn: “Integration of inferno technologies with Eclipse I think is interesting. Implement the eclipse file system api using styx. Create an eclipse console to an inferno shell. Create a limbo editor. Manage namespaces inside an eclipse plugin. Use mk as the project build tool inside eclipse with plugin for mkfile.”

iPhone drawterm

Drawterm is a Unix (including OS X) or Windows application for connecting to a Plan 9 server, giving access to local devices and files; it is a very common way to connect to a Plan 9 installation. Use the iPhone SDK to create a drawterm-like application to run on the iPhone, connecting to a Plan 9 system and making the devices on the iPhone available. This will be development in the iPhone environment, not the Plan 9 environment. The implementation will certainly involve C, and may involve Objective C or other languages as required by the iPhone SDK. Minimally, this should involve exposing the frame buffer and pointer, but should also target audio, the iPhone’s virtual keyboard, and local file access.

IMFS

An Instant Messaging filesystem would be rather useful, and a fun entry-level project for a student to get used to 9P and Plan 9 / Inferno concepts. IMFS would provide a filesystem interface to various Instant Messaging protocols (or at least MSN as an initial target). Preferred for Inferno using Limbo if mjl is to mentor; C in Plan 9 is also acceptable.

Kernel-based 9load replacement

Currently, Plan 9 and Inferno boot native on the PC using 9load, which is related to, but different from, the normal Plan 9 kernel. In particular, each driver needs to be tweaked, and 9load gets some of its own limitations. It would be nice to be able to replace 9load with a standard kernel. This would be a combination of ‘init’(‘boot’ in Plan 9) program, boot scripts and a bit of build system work; mostly in C and rc (the Plan 9 shell). All the kernel work is already done, only writting the user space to run under the kernel needed. See this page for a full description of the project.

Libdraw / devdraw port to Win32

It would be useful to have a native Win32 port of libdraw and devdraw to Win32. This would allow for killing the old sam port, and for native Win32 applications that have a Plan 9 look and feel.

Linuxemu improvements

Plan 9’s unique environment can make porting some large applications a challenge, even assuming source is available. For cases where a port is either infeasible or undesirable, we have linuxemu, a user-mode tool which allows us to run a wide variety of unmodified linux applications on a Plan 9 system. This is project requires substantial knowledge of C and the linux kernel and system call interfaces.

Native Omero

Omero is an Inferno-based system for encapsulating applications and interfaces in a novel manner. Applications present their capabilities, which independent interfaces can connect to. Multiple interfaces can connect to the same application. Create an interface for the o/mero system on a mainstream OS using that OS’s “native” widgets. A very useful native port would be to Plan 9.

New Platform Ports

Plan 9 and Inferno have run on a variety of odd little devices, different workstations, and so on. As a community, we like seeing more of these around. We especially like currently-produced platforms that’re likely to be around for a while, lest the effort be wasted. In particular, one interesting device is the Nintendo DSi. We’ve got a functional Inferno port to the DS, so extending to the DSi would largely be driver work for wireless, the camera, and so on. We find it particularly interesting because it’s mass-market, readily available, likely to stick around in numbers for a while, and fairly novel (and because we’ve got an interested mentor).

Mailer (upas) Replacement or Upgrades

From Sape: We could use a new mailer to replace the upas mess. A potential idea for a new mailer system includes something similar to the way that GMail works: mail is never deleted nor moved from the “Inbox.” Instead, a “databaselet” is constructed around the mail files, which annotates them with attributes such as “unread,” “spam,” and “discard.” Some of these would be managed from the mailer; others would be added / removed by the user. A small search engine would find mail messages. Alternatively, nupas/fs could do with a multithreaded partial rewrite.

Parrot on Plan 9

Plan 9 suffers from a lack of dynamic languages (which is a blessing and a curse). A port of the Parrot VM would bring us several dynamic languages which are able to interoperate through the same interpreter. Currently, Parrot supports python, perl 6, ruby, javascript, tcl, BASIC, APL, and LOLCODE (each language is in varying stages of development). We would need to get a Perl 5.8.4 interpreter running on Plan 9 first, which is an early dependency.

Port 9vx to Windows

9vx is a great way to use Plan 9. It uses the vx32 virtualization library to provide an entire running kernel in user mode, with good integration with the host environment. Unfortunately, while several Unix-like systems are supported, there is no working port to Windows. Port 9vx (first porting vx32) to a modern Windows operating system.

Ventilator

Venti is an archival data service originally written on Plan 9 and now available on Unix via Plan 9 from User Space. Plan 9’s main file system, fossil, can optionally use venti as a permanent backing store, and there are systems like vac which can provide read-only file trees from venti storage. Implement an Inferno application which produces a venti-backed file server for use by the rest of the system. Implementation could be either in C (via a built-in module) or, preferably, Limbo. The file server needn’t be nearly as complicated as fossil. Interesting aspects to consider are disconnected operation, snapshots, and caching.

Virtual Machine support for Plan 9

Plan 9 runs well in a number of virtual machines. It would additionally be nice to get a virtual machine to run on Plan 9. In addition to the utilitarian purposes commonly cited for VMs (running multiple system types, application isolation, configuration management, &c), it would be nice to be able to explore how Plan 9 can extend its strengths in resource sharing and distribution to a virtualized environment. A port of QEMU has been attempted in the past; the work is unfinished, but available. Other likely candidates for consideration are KVM or lguest, each presenting some unique challenges. This would be primarily user-mode C programming.

Zeroconf Networking

Implement some or all (depending on ability and timeframe) zeroconf-related RFCs in Plan 9 and / or Inferno. In both cases, this will involve hooks into dns and ndb/cs; in Inferno, it likely also involves hooks into ndb/registry.