Here's a quick update for week 16. I didn't have internet access over the past few days due to a technical issue with my ISP and hence the delayed report.
TL;DR – The patch to prevent the kernel from overwriting the loader was merged last week. The next issues that need to be tackled are the KDL faulting when printing the backtrace and fixing an assertion that fails when initializing virtual memory.
This week most of my time was spent working on getting WebKit2 compiling on Haiku. WebKit2 is the new multi-process model for WebKit. It replaces the old WebKit1 that our port uses currently. WebKit2 spawns a new process for each tab, and possibly more (for network access, etc.). The key features are:
- When a webpage crashes WebKit, only the tab showing this page is lost, not the whole browser
- The use of more processes makes the application feel more reactive. As you know, the threading model in WebKit is not a perfect fit with Haiku's one, but splitting things in a separate process allows us to have a standard Haiku application as the visible browser shell
- All the tricks of getting WebKit running (specific tweaks to BApplication and BWindows) are moved to the rendering process. This makes the BWebView API much simpler, as it will become just a plain subclass of BView, with no expectations on the BApplication or BWindow
- The WebKit2 API is where all current WebKit development happens. WebKit1 lacks support for some features
TL;DR - It was decided that reserving space for the kernel instead of moving the entire memory map to a higher location. I’ve been working on that for most of last week and I think it would take a good part of this week to complete it since I seem to be running into many issues.
The quest to provide a better web browsing experience continues this week with some small fixes which result from hours of tracking down bugs.
Here’s the update for week 14 of work on the Haiku ARM port. I was travelling for a good part of week 13 and thus couldn’t get much work done during the time.
TL;DR - The problems of kernel overwriting the loader code and the exceptions when setting up framebuffer have been temporarily solved. The framebuffer related code has been disabled for now and the entire memory map moved to a higher address(when FDT support is implemented, a lot of these problems probably won’t arise). Currently, a fault is raised when the kernel attempts to obtain the same lock twice, which drops to KDL.
As mentioned in the previous report, two weeks ago I attended the RMLL conference. As usual this was quite interesting, and an occasion to show Haiku to more people in the free software community. We got only about 10 persons attending our conference and 4 attending our workshop on making Haiku packages. However, the main event was the "Libre Village" where we got to meet people and try to get as much of them as possible to try Haiku. I played Critical Mass with some people there, and also helped porting PyTouhou to Haiku.
Here’s a quick update for week #12.
TL;DR - The decompression process fails because the archive is present in a location that isn’t mapped by the MMU and subsequently allocated for the zlib output stream. No solutions have been discussed yet. It shouldn’t be long till the kernel is running hopefully :).