Since I started publishing my Learning to Program with Haiku lesson series back in January, I have, on many occasions, seen comments asking for lessons aimed at current codemonkeys who want to break into development for Haiku. Here begins a new series of programming lessons aimed at people who already have a basic grasp on C++: Programming with Haiku.
The direction of the series is pretty straightforward. First, we’ll be spending some time (i.e. the first unit) delving into some less-commonly-used features of C++ which show up in Haiku from time to time. This is partly to bring up to speed those who are picking up the series after finishing the first one, but also to examine ways that features like containers from the Standard Template Library can be effectively used in combination with the Haiku API. There’s even a quick primer on source control thrown in for good measure – something which any developer should at least understand, if not use religiously. Following the first unit we will dig into the API. Depending on how things work out, there may or may not also be a crash course on GUI programming in there before diving into the kits themselves. Some of the lessons will deal directly with getting to know a particular kit. Others will examine important topics or the “Haiku way” of getting a task done. They should provide a good working knowledge of Haiku development methods that can easily be expanded into more advanced usage.
It was a fine, sunny morning in Brisbane, Australia: home of the Third Annual Haiku Down Under Virtual Conference for Haiku Users and Developers. Virtual in the respect that the event was streamed live over the Internet via the uStream service. We accept (and regret) that this service requires Flash, so you can’t use Haiku to view this event, you must use another OS like Windows, Mac or Linux.
This year, HDU (short for Haiku Down Under; not slang for How Dare yoU) were able to book a conference venue at The University of Queensland with projector, white board and limited seating where myself, Sikosis was joined by BeMark and Mojodale.
The coding period of the Google Summer of Code is now over since this Monday,
and it's time to give to the Haiku Community a debrief of what has been done on
my initial project, what has been modified, and what remains to do.
The fundamental parts of the journal code are finished. Although they still need more testing, and they can change as more of the Ext3 code is written, they are ready for supporting the first steps in write support for ext2 and ext3 volumes. This blog post explains the code, and how it is organized to handle ext2 and ext3 volumes.
Over the next few weeks, I'll be trying to document some tangible non-C/C++ tasks.
They'll usually be things that I've wanted to do or have been meaning to do, but
for whatever reason haven't gotten around to doing them.
For each task, there'll a description of what it is,
how it helps the project, and hopefully some information to help you get started.
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.
So, I’m still working on the locale kit. Here are some things I did since last time :
The book is finally done! Getting through the proof copy took so much longer than I ever expected. Luckily, right now I’m out of town with a lot more time on my hands, so I had a lot more time to be able to sit down and get through it. It has been published through Lulu.com so that a great deal more of the profit from the book goes to me instead of the pockets of a book retailer. Here is the link to the book and e-book.
There is great news from the 2010 GSoC midterms… Atis’ GSoC work thus far on IPv6 has been merged into the main-line Haiku trunk by Axel due to its quality.
Apply the buildfile diff attached to this post, to any post-r37604 sources to give IPv6 a whirl. Please keep in mind the IPv6 code is still extremely early, using IPv6 may result in dreaded KDL’s and other general bugginess. See below for Atis’ example usage of the IPv6 modules.
Bug reports on the new IPv6 support can be made on Trac under the Network & Internet » IPv6 component.
The LKL-based Haiku driver has progressed well in the last few weeks.
The set of features already implemented:
- mounting and unmounting ext3, ext4 disk images*, both read-only and read-write
- listing file system attributes (read-only/read-write, file system size, number of files created, number of files remaining to be created, etc.)
- browsing the contents of any folder on the file system
- listing file permissions, owner, group, type (directory, symlink, regular file, etc.)
- opening/closing existing files, and creating new files
- reading and writing data into files
- creating new directories
What still needs to be done:
