Since some time, I am working on a replacement of our current shell script based boot process to something more flexible, a similar solution to Apple’s launchd, and Linux’s systemd.
While there is still a lot to do, it’s now feature complete in terms of being able to completely reproduce the current boot process.
Since the switch to our package manager, there was no longer a way to influence the boot process at all. The only file you could change was the UserBootscript which is started only after Tracker and Deskbar; the whole system is already up at this point.
The launch_daemon gives the power back to you, but also allow software you install to automatically be started on system boot as well. You can also even prevent system components from being started at all if you so wish.
As you might have noticed, the WiFi encryption bounty ends tomorrow. Obviously, this is a good time to give an overview over what I did in the past weeks. Unfortunately, and hopefully before I got you excited, the most interesting thing of the bounty, the wpa_supplicant, does not work yet. I've ported it to Haiku, but so far it has resisted my attempts to find out where the problem is located -- well, in the hours I put into debugging I've found a couple of potential causes, but there is at least one more to be found, and fixed.
I've been working on getting WPA encryption to work on Haiku. While I haven't been able to invest as much time as I hoped for before, I made a bit of progress that at least justifies a small status update.
The first part of WPA related work has actually happened while I was working on the network stack for Haiku Inc., as it was not possible to inject packets into the network - while you could easily monitor all incoming packets, there was no mechanism to send packets for arbitrary protocols. I've extended the AF_LINK protocol to be able to deliver that mechanism.
First of all, thank a lot for your generous donations! It was really stunning to see how much money could be raised in such a short time. And since it’s been some time since my last commit, I thought it would be a good idea to report what I’m currently up to. But first, let’s have a look at what I did last week for the most part:
- I started to fix some annoying bugs in the FreeBSD compatibility layer. Now it's possible to unload the networking stack completely again, and the "callout" implementation should provide more accurate timing. Oh, and booting over the network didn't work either anymore with FreeBSD drivers. Originally, I wanted to find out why Haiku would instantly reboot on one of my machines, but the problem mysteriously vanished once I started looking into it.
- Next on the list were some minor bugs, mostly having to do with routing, some could crash the system, others would just render your network unaccessible. Most of those bugs were reported by Atis Elsts, one of our current GSoC students that works on implementing IPv6. I've recently committed his work in progress to our repository in order to ease reviewing his patches, and give what he has done so far a bit more exposure.
- Then I started to integrate the ICMP patches that two former students (Ivo Vachkov GSoC 2007, and Yin Qiu HCD 2008) produced by pretty much rewriting it. Looking back, it was not well spent money: neither student joined the project, nor was the quality of their work really acceptable. It took me 3 days to rework it, and it still has some issues like introducing an IPv4 specific error mechanism to the protocol agnostic stack. I doubt it would have taken much more time to write it from scratch. I will continue to work on this later, though, and address its remaining shortcomings. The current state is that we can produce ICMP error messages (and will in most appropriate places), and also forward those errors to userland applications. For example, if you send a UDP packet (through a connected socket) to a port that is not served, the server will answer with an ICMP port unreachable error (even if that server would be Haiku), and your application would retrieve the appropriate error code from its next socket interaction.
Since the last three days, I'm working on changing some stack internals that caused a bit more work than I originally anticipated: the network stack that is currently in Haiku only allows a single address per interface. This is something that was quite okay with IPv4, but starts to be problematic with the adoption of IPv6, since it's common there for an interface to have more than a single address (this feature is also requested by the RFCs that cover it). Originally, I had thought that simple aliasing of interfaces would do it (the plan was that several interfaces could use the same driver, but had different names that would only be joined for displaying them through ipconfig), but even though other systems seem to actually do that, it's quite a limited approach. Besides, the network stack support for this was utterly broken. That's probably what you get when you don't consider a feature important.
You are probably aware of the existance of chkbfs. This tool checks the file system for errors, and corrects them, if possible.
Nothing is perfect, so you might not even be asking yourself why a journaling file system comes with such a tool.
In fact, it wasn't originally included or planned in the first releases of the new BFS file system. It was added because there is a real need for this tool and you are advised to run it after having experienced some BeOS crashes.
I recently looked into why BeIDE’s interface did only have green squares where its icons should have been (bug #313). The function importing the client’s bitmap data did not work correctly, and while playing with it, the app_server suddenly crashed, and continued to do so in a reproducible way.
How was this possible? Bitmaps are located in a shared memory pool between the app_server, and an application. Unfortunately, the app_server put those bitmaps into arbitrary larger areas, and put the structures managing that space into those areas as well - like a userland memory allocator would do. However, if a client clobbered memory outside of its space in those areas (and that’s what buggy clients do all the time), the structures could be easily broken, which caused the app_server to crash when it tried to use them next time. Also, since all applications shared the same area, they could easily clobber bitmaps of each other, as well.
Since a few days, we have a working APM driver in our kernel. APM stands for Advanced Power Management. It’s a service as part of the computer’s firmware commonly called BIOS in the x86 world. The latest APM standard, version 1.2, is already almost 10 years old. Today’s computers do still support it, even though the preferred method to have similar services (among others) is now ACPI, or Advanced Configuration and Power Interface. Thanks to Nathan Whitehorn effort and Intel’s example implementation, we even have the beginnings of ACPI support in Haiku as well.
If you’ve used BeOS, you’re probably familiar with the above message when trying to unmount a volume. From time to time, some application keeps accessing a volume, and you can’t determine which application that is. It might be caused by a running live query, but it might also be caused by buggy background applications that forget to close a file.
I’ve just given you control over your volumes back again in Haiku: you can force unmounting such a volume – applications still trying to access it, would get an error back. Forcing an unmount requires an extra user interaction, though, so it’s not the preferred solution.
My official employment at Haiku has ended now. I wanted to thank you for all the donations that made this possible. In retrospect, it were pretty busy months for Haiku, I think I have committed over 600 changes during that time, lots of minor ones, of course, but also a few bigger ones.
In case Haiku runs on your system, you should now be at least able to experience uptimes of several hours, depending on what you do, of course :-)
Instead of completing the paging implementation, I got distracted with a couple of crashing bugs that showed up while testing Haiku, and they kept me busy for the last few days. Strangely enough, I could reproduce each bug easily only on different systems.
At least, I could now run Haiku with BitmapDrawing and Pulse in the background for over an hour (after which I shut it down myself). While playing around with it, I found some weird behaviour with the Backgrounds application which I am currently working on. If those problems can be fixed quickly, I will have a look at enabling Deskbar add-ons and replicants under Haiku.
