This report covers hrev58292 through hrev58368.
This report covers hrev58188 through hrev58291.
This report covers hrev58043 through hrev58187.
We’re now back to development “as usual” after the release of R1/beta5 (though some of the changes in this report did make it in to the release itself.)
This report covers hrev57901 through hrev58042.
R1/beta5 was of course released just a few days ago, and many (though not all) of the changes in this report made it in to the release.
Introduction The goal of this post is to document the changes I’ve successfully made during the GSoC period, the current state of the project, future enhancement goals, and a few other topics. I also want to extend my thanks to the Haiku developers and community for the opportunity to work on this fantastic operating system.
Background Haiku is a truly innovative operating system. One of its most interesting approaches to a filesystem lies in the fact that it makes metadata a primary characteristic of the filesystem.
Gerrit Submission. Check out my final Pull Request here: 8141
Overview During this GSoC period, I focused on developing the virtio sound driver for Haiku, aiming to enhance its performance as a guest OS in virtualized environments. This journey began with some challenges, for example, initially, I missed a small detail in the driver module path, which prevented the driver from loading.
One of the significant setbacks, I had, was understanding hmulti_audio.
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 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 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.
Project overview 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.
So I’ve implemented mouse support. It also turned out to be really easy to fix text rendering. So, what’s next? Well, some websites like https://discuss.haiku-os.org cause WebKit to crash. This crash also seems to affect other websites. Really, it seems to occur anytime WebKit decides to use multiple bitmaps (actually, in WebKit lingo, backing stores) to render a web page. Rendering a single bitmap is easy, just display it! But when you have multiple, you need to composite them together.
