gsoc-2024-ideas (as of Wed Jan 31 17:06:17 PST 2024)

IDEAS FOR PROSPECTIVE CONTRIBUTORS


FXR/LXR-LIKE TREE COMPARISONS FOR PLAN 9

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.

PROTOFS

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.

EDWOOD — COLORED TEXT

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.

IMPROVING DTRACY: BACKTRACES

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.

IMPROVING DTRACY: ARBITRARY TRACE POINTS

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

DEVDRAW IMPROVEMENTS: PERFORMANCE

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.

A VECTOR LANGUAGE

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.

PDFFS: FONT RENDERING

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.

DRIVERS: ALWAYS WANT MORE

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.

A SOLID BENCHMARK SUITE

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.

TESTING FRAMEWORKS AND SUITES

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:06:17 PST 2024 [ Current version | Changelog | Create a new page ] About the server | Powered by Plan 9