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:
Hello readers !
Last week we were at the RMLL (Libre Software Meeting) in France, with François (mmu_man) and Olivier (oco). Haiku has beed holding a booth and giving some talks in this conference for some years now, and it’s nice to go and meet people again.
Hello readers !
As you know, I’m currently working on the locale kit to bring it to a more polished state. The work is going well, and it’s about time for a status update. I’ve been quite busy at school for the whole year and committed few time to Haiku, so I’m catching up with a lot of things.
It's been a month and half since the very beginning of the GSoC coding period, and this is
my first blog post about Services Kit. In fact, it's quite difficult to write interesting things
for both developers and non-developers, I waited to have some materials before writing a report of
my work and ... it's time !
If you manage to build complex applications over the original BeOS Network Kit, you will quickly
face a major problem. Indeed, if it's a good C++ wrapper of the BSD sockets API, it's only a
wrapper, providing useful classes to handle a network link, but no more. Services Kit is here
to provide a more complete set of useful classes which will let developers to get rid of internet
protocols and to only think of the good part of a web service client application.
Porting LKL to Haiku's kernel API may not have been very hard, but convincing Haiku to load a properly built LKL-based add-on has presented some interesting and challenging problems.
