Unlike BeOS, our kernel includes some pieces of C++ code, which sometimes give a headache when it comes making sense of a stack crawl from the kernel debugger, since symbols are mangled when linked into binaries, which means we must Decode__12CrypticCNamesPCc. I recalled seeing some gcc4 private API to demangle symbols into human-friendly names, but the code doing that, from libsupc++, has been written without concern for the inhabitants of the Kernel Debugging Land, using calls to malloc, realloc and free... But I still wanted to get nicer names, so I didn't give up. I also wanted to be able to get assembler dumps since not everyone has a serial cable to make use of the gdb stub.
Code_Swarm for Haiku video
Today I received an email from Fredrik Holmqvist (TQH, of Bezilla fame) about a video that he recently created and posted on Vimeo. Titled “Code_Swarm for Haiku,” this is a video generated using Code_Swarm, a technology that allow visualizing the activity on a software repository. The video that TQH created was generated from the Haiku subversion commit messages, and shows the period starting from the time Haiku moved to Subversion up until revision 26538. Check it out here; it’s recommended that you watch the HD version in fullscreen. For those who don’t have or want to use Flash, you should also be able to download the source video (1280x720) from Vimeo (account required).
Another few weeks have passed since my last update, so here is another short report on the status of my project.
I hope everyone is enjoying the results of my work that have already been integrated into the main source trunk. Now I am pleased to announce that also the second part of my project is almost finished.
Someday I should write about the start of the 68k port, there is plenty to talk about…
Today^Wnight^Wmornin erh, hmm well, now, I’ll try to do a live report on the issue I left you with last time: getting the kernel to load correctly.
I’ve been getting further recently on the 68k port, as you may know already everything now compiles but the kernel is still largely stubbed, misses drivers, and the bootloader doesn’t load it yet.
I’ve almost finished mmu setup, at least for the 040 ARAnyM emulates.
Been quite busy those days, but I wouldn’t forget to report the remaining days at RMLL… more people, talks, and RMS of course!
Hi there.
Just some quickies on the RMLL, we have so much to do here ;)
The first month of GSoC coding period is almost over and it’s time for a summary.
This month wasn’t particularly easy. I was working hard to distribute my effort between Haiku and my exams accordingly. I must confess, I was probably doing more schoolwork than Haiku :-)
Nevertheless, I did make some progress and now I am very happy to announce some of the first actual results of my project!
It’s been almost a month already since the very first Haiku Code Drive began!
First of all thanks to all of those who have voted me, I was very surprised about the poll result.
Now some updates about my project.
As you know, my project aims to test the stability of the bfs file system. In order to do so
the idea is to first implement XSI Posix semaphores, and then compile bonnie++ which is a benchmark suite
for file systems. To be honest though, XSI Posix semaphore are not really mandatory, because it would be
faster to just port bonnie++ to Haiku, as it would require very few changes (e.g. those concerned locking).
However though, in the long run, Haiku would benifit more if I implement the semaphores previously mentioned,
as it would also make it more Posix compliant.
Just posting a very brief entry to let you all know what’s up with HPET support in Haiku.
So far, I’ve been able to mostly separate all the x86 timers into individual (but still statically linked into the kernel) modules, and have them used based on priority.
Currently, they break booting on my system (qemu works, though, with the ISA timer).
Brief TODO (in no particular order):
- Modify how each arch advertises which timers it supports
- Migrate the other arch timers into modules (low priority, since the other architectures are not fully supported, I believe)
- Move priority & init code into the generic section, out of x86 (this can only be done when all other archs are migrated)
- Implement HPET support (currently stubbed out, but the module is there.)
- Work on system_time()
- Fix the immediate issues with booting and the like
