Articles

Latest Articles

Haiku Network Stack Architecture

This document may contained outdated information, please update!

The Haiku Network Stack is a modular and layered networking stack, very similar to what you may know as BONE.

The entry point when talking to the stack is through a dedicated device driver that publish itself in /dev/net. The userland library libnetwork.so (which combines libsocket.so, and libbind.so) directly talks to this driver, mostly via ioctl()¹.

The driver either creates sockets, or passes on every command to the socket module². Depending on the address family and type of the sockets, the lower layers will be loaded and connected.

Welcome to Kernel Debugging Land...

One of the most important tools of a Haiku kernel developer is the built-in kernel debugger. Nevertheless also developers more comfortable with userland hacking should not be shy to use it, as it can greatly help with various kinds of bugs and problems. This document sheds some light on its basic and advanced features.

Submit Conference

Are you organizing a Haiku-related event? Are you planning to represent Haiku by giving a talk or manning a booth at a conference? If so, then let us know!

Use this form to submit the information about the event, and we will add it to the List of Conferences, Calendar of Conferences and Map of Conferences. For your reference, check out this entry to see the kind of information is being published for these events.

How to Work on the Haiku WebKit Port

This article is out of date and the code linked should not be used for anything right now. Please, refer to the more recent How to Work on WebKit article instead.

To work on the Haiku WebKit port one needs to take some time to get the right environment set up. At the moment the Haiku WebKit port can only be developed on Linux and cross compiled with the GCC4 compiler. So the first step is to follow my tutorial on building Haiku on Ubuntu. On step 5 of the above, please be sure to build the GCC4 cross compiler, not the GCC2 version. If you have already built Haiku with GCC2 on Linux, I recommend renaming your current "generated" directory in the Haiku tree to "generated_gcc2" and then continue with step 5 from the above, setting up the GCC4 cross compiler. Switching between compilers can then be done by just renaming the generated directory, since it contains all compiled build tools and necessary files for each compiler.

Running UserlandFS

The UserlandFS is a file system wrapper for the kernel (similar to FUSE on Linux) which loads file system add-ons in userspace. In this way, it is a great tool for developing file system add-ons without unwanted trips to the Kernel Debugging Land. On top of that, several interesting test add-ons already exist for it in the Haiku source tree, including a network file system with full support for extended file attributes (meta data). The API which a file system add-on for UserlandFS has to implement is almost identical to the "real" kernel file system API, so that it is easy to migrate the add-on to the kernel once it is ready.

Using Snapshots For Short Locking Times

The primary intention of my previous article was to make it very clear why and when locking is needed in multithreaded applications. In this article, I want to present my experiences in writing a new prototype for a replacement of the document model in WonderBrush and how it is manipulated and rendered asynchronously.

Installing Haiku to a partition from Linux

2010-January: This document is now obsolete. We are in the process of consolidating and re-organizing the website documentation. For now please refer to the in-progress website documentation.

This is a guide for you who have already been able to build an image of Haiku under Linux and running that with an emulator such as QEMU or VMWare and want to try Haiku natively with your real hardware.

Disclaimer: Do this on your own risk. I don't take any resposibility for any data loss caused by using this guide.

Understanding the Requirements of Multithreaded Applications

Though I am programming on BeOS since 1999, only in recent years I have slowly become more comfortable with various multithreading related issues in my programs. So I thought I'd like to share some of my experiences here for beginning programmers or programmers skeptical about multithreading. I hope to be extending this as a series of articles to help learn the benefits and pitfalls of multithreading. All with an emphasis on programming for the Haiku API.

Reimagining Deskbar

Body:

Following Deskbar redesign proposal is based on discussion in the 3D-Accelerated Haiku Desktop RFC comment thread. One problem that came up was that current menu designs do not support good organization.

Only ways to organize a cascading menu (or variant like Deskbar and Windows start menu) is to use subcategories and separator lines. One good thing about subcategories is that you have a short description (i.e., folder name) attached to the group of items in the category, but those items are hidden most of the time and inefficient to use. Using separator lines for grouping does not affect efficiency, but does very little to aid usability. They have no describing properties and they do not visually connect items between them.

Many Ideas

Body:

First of all, apologize me for my English, I know it not quite good but Im improving. I have posted before but they have been deleted (I dont know why).

Quality / Stability, Kernel

I wish that Haiku before have been or sooner if possible BeOS clone. Have some security and quality features, i propose that this OS have a memory execution protection, just to make the life easier and secure, just to enforce to make best programming practices. The thing is like this: