Driver Development
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.
Driver Development Presentation at WalterCon 2006
This is a transcription of the Driver Development Presentation given by Axel Dörfler at WalterCon 2006. The slides in HTML format can be downloaded from here. A video of the presentation is also available for download.
Contents
How to Write a Printer Driver
A printer driver in BeOS R5 is an add-on that exports a specific C interface. This add-on is used by the print_server to add a new printer, configure a page, configure the print job, and print the print job on the printer. This article describes how the print_server interfaces with the printer driver.
The print_server is responsible for maintaining common settings. BMessage objects are used to pass settings from the print_server to a printer driver and vice versa. If the printer driver has to return a BMessage object and wants to show the successful completion of an operation, it has to set the field what to the value 'okok'. To indicate an error, the preferred method is to return NULL. In some cases the print_server interprets a value in what other than 'okok' as the failure of an operation. A printer driver should not rely on this; instead, it should return NULL.
Device driver basics
Device drivers are difficult to write. Understanding the hardware can be the hardest part. Often the documentation is hard to read and understand because it is written from a hardware designer's perspective (that is, if you can get the documentation -- many manufacturers are very reluctant to give it out). Drivers work directly with the kernel - a bad pointer can crash the whole OS. And, finally, you can't use warm and comfortable debugging tools, since you are working in the kernel.





