GSoC project ideas

For information about Haiku's participation in GSoC this year, please see this page.

Qualifying students can apply for a Haiku project (see the list of suggested projects below). For details about how to apply, please check out How to Apply for a Haiku Idea.

The most successful Google Summer of Code projects are often those proposed by the participants themselves. The following list represents some of our ideas and wishes for the project. However, suggesting your own idea is always encouraged!

Be aware: API design and kernel-related work requires a higher level of skill, and user interface design usually involves a lot more thought than other work. A significantly more convincing proposal is required for tasks involving those. Getting started with the design early (before the application period ends) is recommended, to maximize your chances of being selected, and allow a larger part of the coding period dedicated to coding tasks.

If you find one of the "big" ideas interesting, but feel that you cannot complete it within the allotted coding time, feel free to suggest splitting it into smaller parts for your proposal.

Students that intend to submit applications on ideas which are also part of other accepted mentoring organizations must coordinate with both Haiku and the other mentoring organization beforehand.

Applications

Improving Haiku's WebKit2 port

Idea description

Haiku has a native WebKit port which uses the WebKit1 API. This port is not complete and there are several bugs and minor problems which need to be fixed. The plan is to replace this with a more up to date port based on the WebKit2 API. Based on the work completed in GSoC 2019, WebKit2 on Haiku is now able to render some web pages. The goal of this project is to continue this work, making the WebKit2 port more reliable, render all pages, handle input events, etc, and make it usable for the WebPositive browser.

Why we need this

The web browser is an important part of the operating system today. It is difficult to attract and retain users if we don't provide a good web browser. When we started our efforts with WebKit, WebKit2 wasn't ready for our use yet, but today it is more mature and it is time to migrate to it.

Better XMPP instant messaging client for Haiku

Idea description

XMPP is a modern communication protocol for instant messaging. It has open standards and several free software client and server implementations.

Currently, the available native clients for Haiku are quite simple and don't even allow to replace all IRC features. The goal of this project is to improve Renga, one of such clients, to make it possible to migrate Haiku discussion channels over to XMPP instead of IRC.

The main features to implement are more complete support for multi-user chat (in particular, moderation aspects, allowing to manage channel permissions, kick and ban users, etc) as well as any other feature considered useful: activity notification, pictures and file sharing, whiteboard collaboration, …

Why we need this

Most of Haiku communication channels are currently hosted on IRC servers. IRC is a simple protocol, but it lacks modern features and is difficult to use from unstable connections or using mobile phones. As a result, IRC is less popular, and a part of the Haiku community doesn't use it anymore.

Since we prefer to support open source software and usage of Haiku, XMPP is a good candidate, if we can have a working native client allowing to use it. We don't want people to instead use closed-source software or undocumented protocols.

VirtualBox port to Haiku

VirtualBox is a virtual machine allowing to run an operating system inside of another. Porting it to Haiku would allow Haiku users to run another system, such as Windows or Linux, when they need to run an application that is not yet available for Haiku. This would make using Haiku as their primary operating system a viable approach for more people.

Starting from this preliminary work, continue and complete the port. This includes writing a native GUI for VirtualBox, getting it to run, and more importantly, work on the virtualization driver which will allow virtualbox to run the emulated machine using the native CPU. This makes the emulated system run at close-to-native speed, whereas a software emulation would be unbearably slow.

Skill set: userland development, kernel development, possibly x86 assembly
Possible mentors/knowledgeable people: mmu_man
Project size: 350 hours
Difficulty: hard

Hardware acceleration for Haiku's QEMU port

QEMU is a virtual machine which allows running an operating system inside of another. While there already is a Haiku port, it currently does not support any acceleration system through native virtualization (through Intel VT-x and AMD SVM.) This makes it too slow for many uses. Fixing this would allow Haiku users to run another system, such as Windows or Linux, when they need to run an application that is not yet available for Haiku. This would make using Haiku as their primary operating system a viable approach for more people.

Various systems exist on other operating systems for this, such as KVM on Linux, bhyve on FreeBSD and recently (in 2019) NVMM was added to NetBSD. Intel also has a cross-platform framework called HAXM which only works on their CPUs. All of these work with QEMU, while only some work with other virtual machine technologies like VirtualBox. Of all these NVMM seems to be the easiest to port to Haiku. Bhyve might also be viable, and has been ported to MacOS and Illumos (a Solaris derivative.) A student interested in this project should research NVMM, bhyve and some of the other virtualization systems and describe how they would approach a port to Haiku. Many times these systems make use of kernel technologies that Haiku lacks and so much of this project might involve adding those to Haiku's kernel.

Work on a virtualization driver which will allow QEMU to run the emulated machine using the native CPU.
Skill set: kernel development, userland development, possibly x86 assembly
Possible mentors/knowledgeable people: mmu_man, waddlesplash
Sourcecode (QEMU for Haiku)
NVMM Sourcecode
Project size: 350 hours
Difficulty: medium/hard

Devices preferences/Hardware manager

Haiku is meant to be an easy to use graphical operating system. It should provide a GUI to manage devices and drivers. This is currently implemented in the "Devices" preferences, however it does little more than listing devices found on the machine.

The goal of this project is to extend the functionality of Devices preferences to make it a more complete and useful tool. This includes working on the following features:

Telling wether a driver is loaded for a given device and where the matching /dev entry is
Giving user readable information on the device type and subtype
Allowing to block/disable the driver for a given device
Support for USB and bluetooth devices (currently not listed at all)
Generation of a "compatibility report" to help populate a hardware compatibility database for Haiku

Note that a lot of the work may be in making the required information available from the drivers and existing device management infrastructure, and not just in building the GUI itself.

Skill set: user interface, kernel and drivers interfacing (ioctl, devfs...)
Possible mentors: PulkoMandy, waddlesplash
Existing code: "Devices"
Project size: 350 hours
Difficulty: easy/medium

Other applications

There are many open source 3rd party applications for Haiku that could use improvements. Whether it is resolving bugs, adding features, updating the coding style, updating them to use the Locale and Layout Kits, or anything else imaginable! Writing applications from scratch is also possible.

Skill set: userland development, user interface design, exploring an existing code base, others depending on the application retained.
Possible mentors/knowledgeable people (depends on chosen application): PulkoMandy, Sean Healy, waddlesplash
Project size: 175 or 350 hours depending on the application being worked on
Difficulty: easy, depending on the application chosen

Drivers

GPU acceleration support

Haiku does not currently support GPU acceleration, for 3D or otherwise. Reusing most of the DRM drivers from Linux, and Mesa's Gallium userspace components, the goal of this project is to enable the use of GPU-accelerated OpenGL, and eventually also OpenCL and Vulkan.

Haiku's current video drivers are mostly modesetting-only, and split in two parts: the driver itself, which is quite minimal and only provides low level access to the video card, and the "accelerant", which runs inside app_server and communicates with the driver in order to configure the card and use its features.

Porting the DRM drivers from Linux will be a rather daunting task, as they use a large subset of the Linux kernel APIs. It may be possible to reuse OpenBSD's or DragonFlyBSD's work rather than writing our own Linux API compatibilty layer; more investigation is needed here.

Skill set: kernel and driver development, Mesa graphics stack
Possible mentors/knowledgeable people: waddlesplash, PulkoMandy
Project size: 350 hours
Difficulty: hard

Kernel

epoll or kqueue implementation

Haiku is cmpatible with POSIX, but high performance kernel APIs are sometimes required that are not yet part of the standard. epoll and kqueue are an example of this, they are available in Linux and FreeBSD respectively and allow more efficient implementation of working wiht multiple file descriptors. The way this is done in POSIX is using the select or poll system calls, but these two require each call to send the complete list of file descriptor to the kernel over and over again. epoll and kqueue avoid this by having an initial call to set up a list of file descriptors, and a separate call to wait for events on these descriptors.

The goal of this project is to review the APIs for epoll and kqueue and see which one is more appropriate for Haiku. Then the needed system calls and C library changes should be implemented. In particular, integration with existing Haiku specific APIs (wait_for_objects, ports, semaphores, ...) should be considered.

Possible mentors/knowledgeable people: PulkoMandy
Skill set: UNIX application development, kernel development
Project size: 175 hours
Difficulty: medium

Power Management

Haiku already has some power management support in the form of a CPU idling driver. This is however clearly not sufficient, and there is room for improvements in several areas in order to make Haiku use less power and make laptops running Haiku last longer on battery.

Some investigation is required to identify the main issues in Haiku leading to suboptimal performance. There are however a few already known problems:

Some subsystems such as the network and wireless stack wake up the system at regular intervals (10 or 100 times per second) to perform some tasks. Whenever possible they should be modified to trigger these tasks in an event-driven way (triggering them from hardware interrupts for example).
Some applications (such as the always-running DeskBar) are polling for events in a similar way. The APIs should be adjusted where possible to make those applications wait on notifications instead.
None of the device drivers in Haiku include powersaving modes. When a device is idle, it should be put to sleep and powered off until it is needed again.
Skill set: kernel development, general C/C++, userland development, debugging, power management / measurement
Project size: 350 hours
Difficulty: hard

Improving the btrfs filesystem

Haiku has great support for its own file system, but most others are only available read-only. It is way better for interoperability with other systems to be able to write to these disks from Haiku.

The goal of this project is to complete the btrfs filesystem, to allow it to write btrfs volumes (reading works already). During GSoC 2017 and 2018, students got as far as creating directories, but it is not possible yet to write files. The first part of the work is to review the existing code, and report on the current status and the work needed to get everything in place.

After completion of this project, it should be possible to read and write files to btrfs volumes, making sure they are interoperable with Linux (mount without errors, file data is accessible, fsck detects no problems). Stress-testing should also be performed using bonnie++, and other test suites may also be used.

Skill set: kernel, and driver development
Possible mentors/knowledgeable people: PulkoMandy, Sean Healy, Hy Che
Sourcecode
GSoC 2017 log
GSoC 2018 log
Existing btrfs patches to start from
Project size: 175 or 350 hours depending on the number of features planned to implement
Difficulty: medium

Adding write support for more filesystems

Idea description

Some filesystems can only be read, but not written, from Haiku. The goal of this idea is to add write support for one of these filesystems (of your choice, from the list below).

XFS (Development community, homepage) is a filesystem originally developed for the IRIX operating system. Today it is commonly used by Haiku developers who build Haiku from Linux, because of its better support for extended filesystem attributes (unlike ext4). Update: You are recommended to look at the current status of XFS. We are in the process of merging XFS v2. XFS v3 has been out for a long time and bringing read support for it could be a better idea before jumping to providing write support. This may require some discussion and we encourage you to reach out to us.
UFS2 (FreeBSD implementation, u2fstools for windows) is the default filesystem in FreeBSD, commonly used by some Haiku developers as well. It is closely based on the original Unix filesystem, which is implemented in many other operating system. The original design is quite simple, however the different implementations in various systems make it a bit more complex to handle all cases. Focusing specifically on the FreeBSD variant is acceptable for this project if needed.

Why we need this

In its current state, Haiku is rarely used as the single operating system on a computer. It is common to dual boot it with other systems such as Linux or FreeBSD. In this setup, it is very convenient when each system can access and modify the other's files. Disk partitions and data can then be shared more easily.

Further details

Skill set: data structures, C++
Possible mentors/knowledgeable people: PulkoMandy, waddlesplash, Hy Che
Project size: 175 or 350 hours (in 175 hours only partial progress will be possible)
Difficulty: medium

Filesystems benchmarking and stress-test

Some of the filesystems (or specific features of them) in Haiku are relatively new, and not considered perfectly tested and stable yet. The goal of this project is to define a procedure for testing the filesystems and identifying bugs (especially leading to on-disk data corruption) and performance bottlenecks.

Tools like bonnie++, xfstests, and the existing tests in src/tests/add-ons/kernel/file_systems in Haiku sources should be explored to determine their respective usefulness. Then, an automated way to run the tests should be defined (unit tests, integration tests on a running system, etc.)

Then, the filesystems should be modified to fix the performance problems and/or bugs that were found in the process.

Skill set: C++ development, testing
Possible mentors/knowledgeable people: PulkoMandy
Project size: 175 hours
Difficulty: easy

x86-64: Implement support for Process Context Identifiers (PCID)

on Intel CPUs. The feature tags TLB entries with the Id of the address space and allows to avoid TLB invalidation on the context switch, it is available only on x86-64.

The goal of this task is to propose possible designs, implement the feature, extend the performance logs to measure impacts when the feature is enabled, and potentially also to mitigate the "Meltdown" vulnerability.

Skill set: kernel development, x86 architecture/assembly language
Possible mentors/knowledgeable people: korli
Project size: 175 hours
Difficulty: easy

ARM port and device tree support

Unlike x86 systems which have a PCI bus, most ARM devices have peripherals at hardcoded addresses. This means automatic hardware discovery is not possible. The Linux kernel developers designed a solution called "flattened device tree". It is a static description of the hardware, telling the kernel where devices are located and which driver to use.

Haiku plans to use device trees to support several ARM devices with the same kernel. This requires updating our drivers and driver infrastructure to not rely so much on the PCI bus. This work should start with the USB EHCI driver, in order to provide at least one mass storage solution to the ARM port of Haiku.

The ARM port of Haiku is currently in an early state. This project may involve debugging other issues in the port to get it running further, so that the device tree part can be tested. Several parts of the early boot code should be reviewed to make use of the device tree and remove hardcoded addresses (RAM mapping, framebuffer, serial port, etc).

Skill set: kernel development, ARM architecture/assembly
Possible mentors/knowledgeable people: PulkoMandy, kallisti5
Project size: 175 hours
Difficulty: easy

Network

Bluetooth Stack Improvements

Haiku's Bluetooth stack implements a basic subset of general Bluetooth functionality. This functionality needs to be completed and Bluetooth 2.X and later possibilities explored. This task involves investigating the current state of the Bluetooth code, improving the existing code on newer devices (pairing, etc), and improving the stack to make it more useful by implementing driver(s) for Bluetooth device(s) of your choice (file transfers, audio, HID, networking, etc).

Requirements: Bluetooth-enabled Haiku system
Skill set: C++, kernel development, userland development, global bluetooth stack knowledge (optional)
Possible mentors/knowledgeable people: waddlesplash
Project size: 175 hours or 350 hours (depending on how much of the stack is added)
Difficulty: medium

VPN Support

With the decline of internet freedoms (Government IP Blocks, Net Neutrality reductions), the usage of encrypted virtual networks is increasing across all platforms. Haiku's VPN implementation is severly lacking. To improve global access to Haiku as a desktop platform of choice, our VPN support needs a lot of work. OpenVPN or Wireguard are both great options.

Requirements: Internet connected Haiku system
Skill set: C++, kernel development, userland development, TCP/IP stack understanding
Possible mentors/knowledgeable people: kallisti5
Project size: 175 hours
Difficulty: medium

Integrate our PPP implementation

Finish porting the PPP implementation to our new network stack. Add phone-line modem support, including HDLC framing and VJC compression (porting both algorithms is sufficient, but make sure the license is compatible to MIT). Implement CHAP authentication, and add support for configuring these to the new network preflet GUI. Find and fix bugs.

Tickets: #812, #869, #873, #922, #923, #1059, maybe: #1057, #1058
Skill set: multi-threading basics, maybe network protocols and some kernel/drivers development, maybe UI development
Project size: 175 hours
Difficulty: easy

IPv6 finalization

The base framework for IPv6 support was implemented as a Google Summer of Code 2010 project. Even so, there remains a lot of smaller cleanup/finalization tasks that can be done as a project.

Tickets:
- #8293 -- BNetworkAddress needs to check if there is an available IPv6 connection.
- #7228 -- RFC: BNetworkInterfaceAddress needs to store auto-configuration flags
- #6489 -- ifconfig needs to validate availability of ipv6 module prior to utilization
- #2632 -- Possible redefinition for struct sockaddr_in, related to IPv6
- #8319 -- Haiku needs IPv6 duplicate address detection during link scope ip configuration.
- #8317 -- Haiku needs IPv6 global scope Auto Configuration (router advertisement + DHCPv6)
- #11862 -- Net server multi-protocol rework

Skill set: IPv4 and IPv6 protocols, kernel and network stack development
Possible mentors:
Project size: 175 hours
Difficulty: easy

MDNS / Bonjour / Avahi network discovery

Idea description

MDNS (known as Bonjour for Apple devices and usually implemented using Avahi on Linux) is a protocol allowing to discover devices in the local network and their capabilities. The goal of this project is to implement MDNS in Haiku and integrate it in our name resolution system and user interface.

Why we need this

MDNS is part of the IPP Everywhere and Airprint specifications, which allow to use networked printers with a single generic driver, instead of a specific driver for each printer. Having an implementation in Haiku would allow easier setup and use of printers, a required feature for a desktop operating system.

Further details

Skill set: network programming (UDP, IPv4, multicast)
Possible mentors: PulkoMandy
Project size: 175 hours (350 hours with extra goals such as UI integration, IPP printers support, etc)
Difficulty: medium

User Interface

Modular edit view (BIG)

The current solution for text editing in Haiku is the BTextView. It is a rather simple view providing basic text editing features and limited styling. This is, however, not powerful enough for most serious uses. The goal of this project is to design a complete replacement for BTextView, which should be designed to cover more use cases.

The edit view design should be modular and extensible to make it easy to implement e.g. following features:

spell checker
line numbers, ruler, 80 character limit line, hyper links
working on an input stream rather than on an input file, e.g. to be able to open files ~100Mb without loading them into memory in one go
Including pictures in the text flow
Sourcecode editor: syntax highlighting, code completion
Ability to load and save data in different formats (using the Translation Kit)

Existing work

The HaikuDepot application includes preliminary work on a rich text view, which it uses to provide the description of packages. This could be used as a starting point for this work.

Skill set: C++, API design, UI development
Possible mentors: waddlesplash, Sean Healy, scottmc
Project size: 350 hours (175 hours if working only on a much smaller subset)
Difficulty: hard

Ports

Porting the Go Programming Language to Haiku

Go (or Golang) is a popular cross-platform general-purpose programming language which is known for its direct compilation to static executables, concurrency model used in its goroutines and its enforced standard style of programming. It has been used by many developers to create command-line tools, static site generators, high-performance servers and many other applications requiring Go.

Existing work

There was a previous GSoC student who originally ported Go 1.3 to Haiku, but unfortunately it was unmaintained and was broken over the years. In 2018, the port was later updated to Go 1.4.3 but only for 64 bit. Work has been attempted in bootstrapping higher versions like 1.5 and 1.11 but the bootstrap process have produced binaries that are broken and don't work. The goal of this project is to identify the issue preventing the bootstrap process from completing and then attempt to fully build either a recent version (Go 1.11) or the latest version of Go only using Go 1.4.3 for 64 bit. Please note that this port may require diving into the low-level components of the compiler and Haiku internals rather than primarily programming in Go.

Links:

Skill set: C, Go, Go assembly, low-level programming, ELF-internals
Possible mentors: return0e, BGA
Project size: 350 hours
Difficulty: medium

Other

Jam (build system) replacement/rewrite

Haiku uses Jam as its main build system. Unfortunately, Perforce is not actively maintaining the tool anymore and the codebase is not very clean. Ingo Weinhold started work on a complete rewrite of the tool in C++, with the aim of being compatible with the existing build files, but provide a cleaner codebase to build upon and do away with most of the legacy stuff.

The goal of this project is to continue this work and make ham usable to build Haiku, as well as other projects currently using Jam as a buildtool.

Skill set: C++, threading, build systems
Possible mentors: waddlesplash
Project size: 350 hours
Difficulty: medium

Add Haiku support to Allegro 5.0

Allegro is a gaming library. Older version (4.4) did support Haiku, but this support was dropped from the newer versions (starting from 5.0). The library should be ported to Haiku, allowing to run the bundled examples and possibly port some other software using it.

Skill set: C++, userland development
Possible mentors: scottmc
Alternative projects: porting SFML or another similar library
Project size: 175 hours
Difficulty: easy

Multiple monitors output in app_server

app_server is Haiku's graphics server and the equivalent of X11 or Wayland on other UNIX systems. It currently supports only one video output, but should be able to do more.

While the API already allows this for the most part (with the BScreen class), there is no actual implementation behind it and parts of the code assume only a single screen.

Some drivers implement minimal support for multiple displays, but not all of them. This task may involve updating the video drivers to handle multiple monitors correctly.

Skill set: C++, graphics development
Possible mentors/knowledgeable people: PulkoMandy
Project size: 350 hours
Difficulty: medium/hard

Complex font rendering in app_server

app_server is the graphics server in Haiku. It handles the rendering and display of application windows, desktop, and everything that is shown on screen.

Freetype (in combination with agg) is used to render text. While it provides good results for latin and cyrillic alphabets, Freetype is not enough on its own to properly render other scripts with more complex rules, such as Devanagari or Arabic.

The goal of this task is to integrate Harfbuzz into app_server, so that the complex rules for text rendering are properly applied. This would allow rendering of complex languages as mentioned above, as well as mixing different languages (picking appropriate fonts automatically).

This task can be further extended with investigations of API changes required in the interface kit (and in particular BView and BFont) to properly handle right to left text.

Skill set: C++
Possible mentors: stippi, PulkoMandy
Project size: 175 hours
Difficulty: easy/medium

GSoC project ideas

Project Areas

Applications

Improving Haiku's WebKit2 port

Idea description

Why we need this

Further reading

Better XMPP instant messaging client for Haiku

Idea description

Why we need this

Further reading

VirtualBox port to Haiku

Hardware acceleration for Haiku's QEMU port

Devices preferences/Hardware manager

Other applications

Drivers

GPU acceleration support

Kernel

epoll or kqueue implementation

Power Management

Improving the btrfs filesystem

Adding write support for more filesystems

Idea description

Why we need this

Further details

Filesystems benchmarking and stress-test

x86-64: Implement support for Process Context Identifiers (PCID)

ARM port and device tree support

Network

Bluetooth Stack Improvements

VPN Support

Integrate our PPP implementation

IPv6 finalization

MDNS / Bonjour / Avahi network discovery

Idea description

Why we need this

Further details

User Interface

Modular edit view (BIG)

Existing work

Ports

Porting the Go Programming Language to Haiku

Existing work

Other

Jam (build system) replacement/rewrite

Add Haiku support to Allegro 5.0

Multiple monitors output in app_server

Complex font rendering in app_server

Menu