Usually when you arrive in KDL (Kernel Debugging Land) it means that something bad happened. KDL provides a lot of tools to investigate what might have taken place. Still, it is quite possible that, even though you have that arsenal of tools available, you may not be able to immediately make sense of what is going on. In that case you ideally either continue debugging yourself or you write up a nice bug report over at the Haiku bug tracker so that someone else can take a closer look.
I’m writing this to inform a broader audience of what was/is going on with my Haiku contract work.
Puh, time has passed again and the signals from my side might have been a bit confusing with only the last blog post in mind. Therefore I’m going to explain what provoked that flurry of seemingly unrelated commits and how the KeyStore API is coming along.
As this week concludes I’d like to post an update on what I’ve been up to and what I’ll be working on next. After fixing a few kernel issues and looking into some others I’ve come to a point where I’ll gradually refocus back on some of the tasks I left open before mentally entering the kernel debugging land. In this blog post I’ll also try to describe some of what I did this week to hopefully make it a bit more accessible.
So what is going on right now in the time I spend on my Haiku contract? For the past two and a half weeks I’ve had my mind wrapped around various parts of the kernel. Things started out at BeGeistert and the coding sprint following it. The nice thing about the coding sprint is that you spend a lot of time with very knowledgeable people and can therefore tackle things that you would usually shy away from. In this case, Ingo Weinhold and I were seeing some random memory corruption problems and an apparent memory/pages leak. So we started investigating those by adding more debug functions into the relevant parts.
As some of you know, I’ve started my contract work on Haiku pretty exactly one month ago. During that time I’ve been working on various things that I’d like to summarize in this post. In the future I plan on posting more but shorter entries, but since much has happened in this month this one is going to be a bit more elaborate.
There's plenty of ways to introduce subtle bugs into your code that give you a hard time finding and fixing. In this post I'd like to introduce you to malloc_debug, a heap implementation with added debug helpers, and outline how it can be used to find some of these problems.
<p> Usual question: "I've dd'ed the image to somewhere and now it doesn't boot". Usual advice: "You have to make it bootable by using makebootable". Usual reaction: "Ehm, ok how do I do that?". Since this type of question comes up quite frequently, let me try to explain a bit of background on that pseudo-mystical tool "makebootable", how you can get it and how you can manually make a partition bootable without even needing makebootable.
<p> Out of no real particular motivation I wanted to build a native GCC4 for Haiku. We've had a GCC 4.1.2 cross-compiler for a pretty long time now, but since there were some issues with GCC4 built Haiku installations and especially since there never was a native toolchain for GCC4 based Haiku, it has always been a second class citizen. You could experiment around with it and we've had hybrid builds able to use software for both GCC2 and GCC4 Haiku on the same install, but since you had to use the cross-compiler to build GCC4 Haiku apps it's always been a bit less convenient that just building for GCC2 Haiku.
This article contains outdated information, please read with caution. Mainly in the second half of the last year the Haiku USB stack has matured a great deal. Not only has it stabilized a bit, it has also seen the addition of an EHCI driver to support USB 2.0 devices. A rewritten UHCI driver and a new implementation of the USBKit library are other steps to a complete stack. The reason to write about that is the following: An increasing number of people apparently get interested in the progress of Haiku USB and they start to ask questions about the completeness and usability of the stack.
