History -
Diff -
Top of this page -
Last modified Mon Feb 19 17:10:37 PST 2024
Plan 9 and related technologies cover a wide range of topics. Below we've put together a list of some ideas which we think would be good candidates for contributors looking for GSoC-sized projects with us. Each idea starts with a list of a likely lead mentor, the key skills, the project size, our estimate of the difficulty, and the expected outcome of the project, followed by a more in-depth discussion. Several also contain links to pages with more details and references.
Note that size and difficulty are our estimates but, for several of these projects, both could likely be scaled up or down. If you have any questions about that, please get in touch (see community).
You're welcome to submit proposals for ideas not on this list, too, although you're more likely to be successful if you talk with us about your idea first (see: community). If you're looking for additional ideas, you might look at Inferno's issues list, or Acme-SAC's issues list. These lists are much more general and not everything on them will all be a good size for a summer, but they are good sources of inspiration. There's also our prior editions of this page: gsoc-2022-ideas, gsoc-2021-ideas, gsoc-2013-ideas, gsoc-2012-ideas, and gsoc-2011-ideas.
Likely mentor: Skip Tavakkolian Skills: Go or C Project size: Medium Difficulty: Medium Expected outcome: A web accessible self-service to keep /lib/face up-to-date
Having a centrally maintained /lib/face and importing it would be very convenient. Letting users add themselves and update their profile photo would help keep /lib/face up-to-date and reduce the collective system administration requirements for the community.
A server with a web interface would ask users to authenticate themselves and to authorize the service to obtain users' profile photo and verified email address from their Identity Providers (IdP). Any IdP that supports OAuth2/OpenID Connect would be allowed. The service would convert such profile photos to the faces format (see face(6)) and store them. Users update their photos by reauthenticating and reauthorizing through the web interface.
Separately the service exports its database of users and profile photos as a 9P-based file server that replicates the namespace of /lib/face.
Likely mentor: Jacob Moody Skills: C, assembly Project size: Medium Difficulty: Medium Expected outcome: A new CPU emulator capable of running Plan 9 a.out binaries.
Plan 9 has multiple instruction emulators for mips(vi), power(qi), sparc(ki) and arm(5i). 9Front additionally adds 5e, which is another design for emulating arm binaries. These emulators are quite useful for testing changes in lieu of hardware, and it would be nice to have these cover the full range of supported systems.
We are currently missing native instruction emulators for arm64, power64 and riscv. These are ordered by how mature the surrounding system is (compilers, linkers, debuggers). This project would be to select one of these architectures and write a corresponding instruction emulator capable enough to run existing Plan 9 programs.
Likely mentor: Jacob Moody Skills: C, IP Networking, Cryptography Project size: Large Difficulty: Hard Expected outcome: A Wireguard program capable of peering with other systems.
Wireguard is a modern secure Virtual Private Network implementation that has gained popularity in recent years. It would be useful to have an implementation of Wireguard usable for Plan 9. Wireguard is documented within a white paper and has several independent implementations.
This project would be to implement software on Plan 9 to make it capable of integrating within existing Wireguard networks. This will involve learning the Wireguard protocol itself, understanding the cryptography involved, and how to interact properly with the Plan 9 IP stack.
Likely mentor: Anthony Sorace Skills: C or Limbo Project size: Small Difficulty: Easy Expected outcome: A wikifs(4) which parses markdown source
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 more capable, like Markdown. Markdown engines in C already exist and a few have already been ported to Plan 9; doing the Inferno version would most likely involve a new Markdown interpreter in Limbo. Ths project should also provde a method to convert existing wiki docs.
This project could be expanded to a larger size with some combination of doing both the Plan 9 and Inferno versions (rather than picking one), and possibly exploring different output types (Anthony has a draft of a version that generates gemtext, for example). In any case, it should still be farly easy, in terms of complexity.
See replace language for wikifs for additional discussion and references, including a likely small-sized subset.
Likely mentor: Skip Tavakkolian, Anthony Sorace Skills: C or Go Project size: Medium Difficulty: Medium Expected outcome: 9p server
Write a 9P file server that can be instructed to create a file tree and associate each node with external directories, files or processes. A good starting point would be to use the proto(2) format (hence the name) as used by mkfs(8) and others, although there are some obvious useful extensions for this application. 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
Your application should describe the set of extensions you think would be useful, and ideally your plan for adding those in after first establishing a working base model.
This should be a relatively easy project, although it could be a bit more complex depending on the specific extensions you support.
Likely mentor: Paul Lalonde & Rob Kroeger Skills: Go Project size: Large Difficulty: Medium (High if including all three, below) Expected outcome: Modifications to Edwood to support colored text in windows
Edwood is a text editor based on Plan 9’s acme user interface and programmable interface, rewritten in Go to allow more agile extension. Like acme, edwood is limited to monochrome and mono-font text representations. It allows changing the font on a per-window basis. It does not support any text coloring. This project is to extend edwood with three new interconnected features:
These together should allow external programs to manage syntax coloring, for example. A stretch goal would be to connect established syntax coloring processors to edwood through its synthetic file system interface. Part 1 will require modifying edwood’s text buffer representation to include an attribute per character. A policy will be required to determine what attributes newly inserted text should inherit from surrounding text. Part 2 will require modifying libframe to support color attributes. Part 3 will require developing an interface to compactly communicate the attributes of the visible portion of the text.
Likely mentor: Ori Bernstein Skills: C Project size: Large Difficulty: Large Expected outcome: Teach dtracy to collect/provide backtraces
9front has implemented a dtrace workalike called dtracy. It's already proved useful for collecting statistics systemwide, but has a few gaps. The largest of these is that it does not collect stack traces.
Your proposal should describe the way that you intend to teach dtracy about collecting stack traces from within the kernel, and integrating them into the trace aggregation.
We estimate this project at a large size and difficulty. There are several tricky components to this. Collecting the stack of a user process in an interrupt safe manner will take care, and finding a way to communicate the result to/from the kernel will require a change to the dtracy device data format.
Likely mentor: Ori Bernstein Skills: C Project size: Medium Difficulty: Medium Expected outcome: Allow dtracy to set arbitrary trace points
9front has implemented a dtrace workalike called dtracy. It's already proved useful for collecting statistics systemwide, but has a few gaps. One gap is that currently, tracepoints are inserted manually into the kernel.
In the 9atom fork of Plan 9, the devtrace device was added. This device can send an event whenever entering or leaving a region of memory. If integrated into dtracy, this feature may be used to remove the hard coded set of tracepoints, and allow tracing more arbitrary kernel functionality.
Your proposal should describe the way that you intend to marry trace(3) to dtracy(3).
We estimate this project at a medium size and difficulty. Much of the difficult code has been written, but integrating it cleanly and making it fit is still not trivial.
The second can probably be done by marrying devtrace from 9atom with dtracy:
http://man.postnix.pw/9atom/3/trace
Likely mentor: Ori Bernstein Skills: C Project size: Medium Difficulty: Medium Expected outcome: Code changes to improve the speed of devdraw
Many operations in devdraw are quite a bit slower than they need to be. The memdraw code accepts many arbitrary color channels, with fast paths for some of them, but falls back to poorly optimized paths for anything else. As a result, many common operations such as alpha blended images are slower than needed.
Your proposal will come up with a plan to build a benchmark, and a plan to optimize several candidate operations for libdraw. This should likely include a plan for a vectorized argb32 blending function, though creative approaches are welcomed.
We estimate this project at a medium size and difficulty. However, this project can be scoped to any size required. Like with any optimization project, there is an unbounded amount of work, but the value can be realized incrementally.
Likely mentor: Ori Bernstein Skills: C Project size: Large Difficulty: Large Expected outcome: A new language for vector processing
Related to the devdraw performance improvements, it would be useful to have a crude language for describing vectorized operations, in the style mpc. This language will not be a general purpose language, but will specifically be designed to be embedded in larger C programs, accelerating some part of their vector processing.
Your proposal will come up with a sketch of the language you intend to design, as well as of the compilation strategy you would intend to use for both naive C code and a popular vectorized assembly.
We estimate this project at a large size and difficulty. We expect that the primary difficulty will be compiling to multiple backends, including at least one proof of concept vector backend.
Likely mentor: Noam Preil Skills: C Project size: Large Difficulty: Medium Expected outcome: An improved pdffs which haldles TrueType fonts
Pdffs is the up and coming PDF renderer for Plan 9. Currently, there is a proof of concept that handles a good deal of the complexity of the PDF spec, but which has punted on rendering fonts correctly.
We have most of the components in place to handle at least truetype font rendering, but need to wire it into pdffs and fix the bugs.
Your proposal will include a survey of the state of pdffs, libttf, and other components needed in order to implement correct font rendering in pdffs, as well as a clear description of which edge cases you consider out of scope.
Likely mentor: Ori Bernstein Skills: C Project size: Medium Difficulty: Medium Expected outcome: Drivers for new hardware
Drivers for relatively common hardware (USB wacom tablets, thinkpad bits, wifi, etc) are always welcome; pick a machine that don't work, and make it work.
Your proposal will describe a reasonably common piece of hardware which you have access to, and point out that it does not have drivers. You will describe the basics of operation of the device, and how you intend to approach writing a native driver for the hardware. It's worth noting that a direct port for a drive is rarely successful, because the Plan 9 kernel internal structure is not at all like Unix.
We estimate that this is a medium project, but the scope of this project depends on the hardware you intend to write the driver for.
Likely mentor: Ori Bernstein Skills: C Project size: Medium-large (depending on what's benchmarked) Difficulty: Medium Expected outcome: A benchmarking framework and initial set of specific benchmarks
Right now, it's hard to know how changes to our system affect performance. It would be useful to have a test suite that covers a variety of aspects of the system.
This test suite shold include many basic elements of the system, such as:
- Basic kernel performance: - Task switching - IPC - Synchronization - Language and library performance - Libc functions - Libmemdraw - Network performance: - TCP - UDP - Raw ether - In different situations - High latency - Packet loss - etc
Your proposal should describe how you intend to build the test suite, the kind of harness that would be needed to run it, and what you consider the most important things that could inform system work.
Likely mentor: Ori Bernstein Skills: C Project size: Small-large (depending on test coverage) Difficulty: Low to medium Expected outcome: More test coverage
Recently, 9Front added the crude beginnings of a test framework to the system. Adding a variety of automated tests, fuzzing tools, and other similar ways to find breakage would be quite useful.
This project will likely look at importing test suites such as the awk tests or csmith generated tests in order to verify that our system works as expected, but will also cover tools to break the system.
Your proposal should describe how you intend to approach the tests, which test suites you intend to port and import, and which tools you intend to write.
Likely mentor: Ron Minnich Skills: Go Project size: Large Difficulty: High Expected outcome: syzkaller running on Plan 9
syzkaller is a fuzzer written by Dmitry Vyukov. It's been used to fuzz lots of things, including Akaros, an operating system which includes a large amount of Plan 9 code. It would be good to bring it to Plan 9 proper. We estimate this as difficult, but someone with strong pre-existing syzkaller experience might find it a bit easier than that.
