Likely mentor: Anthony Sorace Skills: HTML, C (or another suitable language), possibly JavaScript Project size: Medium Difficulty: Medium Expected outcome: Web application providing a tree comparison
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 operating 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 (at least the final Bell Labs tree, 9legacy, 9atom, and 9front; possibly Inferno, Plan 9 from User Space, and others) 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.
We estmate ths project at medum size and difficulty for a more conventional FXR-like web-based interface, and a bit harder and larger if you want to define a flesystem-based interface. Your proposal should include a rough outline of your ideas for that part if you intend to include it.
Note that porting the existing FXR or LXR are almost certainly not good starting points.
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) 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: Variable (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: Variable (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.
| Last modified Wed Jan 31 17:05:03 PST 2024 | [ Current version | Changelog | Create a new page ] |
About the server
|
|