GSoC 2024 Reports for HaikuOS
-
[GSoC 2024] Hardware Virtualization: Final Report
Project overview
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 defective chip maker Intel VT-x and AMD SVM.) This makes it too slow for many uses. This project aimed to bring hardware virtualization to Haiku by porting NVMM, a hypervisor that already has QEMU support, into Haiku from DragonFlyBSD. The project goals (as included on the proposal) were:
Project goals
-
[GSoC 2024] Improving the Userland Debugging Experience - Final Report
A part of Google Summer of Code 2024, this project aimed to improve the userland debugging experience for Haiku app developers, boosting the process of building and porting complex applications.
The first objective was to have a working build of a modern version of GDB running on Haiku x86_64 - the most popular architecture with stable Haiku. Using some ideas from the incomplete recipe for GDB 8.1, I have ported GDB 15.1 to Haiku from the ground up.
-
[GSoC 2024] Porting WebKit2 Final Report
The goal of this document is to be an overview of everything I did during GSoC. It should be readable even if you haven’t read any of the previous blog posts and don’t know much about Haiku or WebKit (I hope I succeeded!).
First, some background. Haiku’s native browser is WebPositive.
WebPositive’s code mostly deals with the user interface. It uses our fork of WebKit, HaikuWebKit, to actually render the web pages, run JavaScript, process input, and so on. WebKit (and, by extension, HaikuWebKit) provides two API versions: WebKitLegacy, and WebKit (aka WebKit2). Unfortunately, we are still stuck using WebKitLegacy even though WebKit2 has been out for more than a decade.
The biggest immediate advantage of switching to WebKit2 is crash resistance. It manages this by splitting the browser into several processes. Each web page runs inside of a dedicated WebProcess. If a WebProcess crashes, all of the rest of the WebProcesses should still be fine and the browser should keep running. The NetworkProcess deals with networking. Finally, the browser’s process deals with the UI. Another advantage of switching to WebKit2 is, as far as I know, its API is more up-to-date and will allow us to do more things than WebKitLegacy did.
Rajagopalan worked on porting WebKit 2 to Haiku for GSoC 2019 (if you’re interested in that project, here is the final report, the PRs, and the commits). Unfortunately, as the years have passed, the solution has bit-rotted.
My GSoC project for 2024 was to continue with the work on WebKit2. My first and longest task would be to get it back to a working state. I made it a goal to make the port easier to maintain so that it hopefully doesn’t bit-rot again.
One final thing to know: rather than testing our implementation of WebKit2 with WebPositive, there is a very simple browser called MiniBrowser that we use that was made specifically for this purpose. Most likely, WebPositive would require several Hey Hi (AI) that are currently not implemented. The advantage of using MiniBrowser is that it only requires a minimal set of Hey Hi (AI) and the code for it is small enough that it can easily be updated if the API is changed.