About This Guide

Philosophy

In this first section of the book, I discuss the various “big picture” and architectural issues that you need to keep in mind. This is a condensation (some would say “brain dump”) of the work I've done with QNX operating systems over the years—I've seen what works, and what doesn't. I'll share both, because I think it's important to know what doesn't work too, so you can understand why it didn't work out.

The Basics

In this chapter, the main() function and its friend, the option processing function optproc(), are discussed. It's in its own chapter so we don't have to talk about the things I use in almost every project.

High Availability

High availability is a very interesting topic. In this chapter, I discuss the concept of high availability (what it is, how it's measured, and how to achieve it). We'll discuss such things as Mean Time Between Failures (MTBF), Mean Time To Repair (MTTR), and the formula used to calculate availability.

I'll also talk about how you can design your systems to be “highly-available” and some of the problems that you'll run into. Unfortunately, in a lot of today's designs, high availability is done as an afterthought—this almost always leads to disaster.

By thinking about high availability up front, you'll be able to benefit from having the architectural insight necessary to design highly-available systems.

Design Philosophy

Next, I present an article about the basic philosophy that's useful when building a system based on message passing—the fundamental Inter Process Communications (IPC) model used by all QNX operating systems. We'll take a hypothetical security system example, and examine how the design is derived to meet various goals. We'll look at the design of the individual pieces (things like swipe card readers and door lock actuators) and see how they fit into a larger system. We'll also discuss things like scalability—how to make your software design scale from a small security system to a large, multi-site security system.

Recipes

The second section of the book contains a smattering of small, useful, and well-documented utilities. Each has been tested on a live QNX Neutrino system. Where there are deficiencies, they're noted — software is an ever-evolving creation. I've also tried to pick utilities that demonstrate something interesting that's “special” about QNX Neutrino, and perhaps not well-understood.

You won't find a graphics ray-trace utility here, because that's not QNX Neutrino-specific (even though it may be poorly understood by the general population of programmers). What you will find are examples of resource managers, high-availability, IPC, and other topics.

Each of the headings below is one chapter in the “recipes” section.

Web Counter Resource Manager

This chapter describes a utility that illustrates how to generate graphical images on-the-fly within a resource manager. You've seen web counters on various web pages; the count goes up every time someone accesses the web page. In this chapter, I'll show you how this can be done with a neat twist—the web counter looks and acts just like a plain, ordinary file. The “magic” is all done via a resource manager. You'll see how to maintain context on a per-open and per-resource basis, how to handle the file content generation, and so on. The chapter presents the project in three phases—a kind of “building-block” approach.

ADIOS — Analog/Digital I/O Server

This project is a data acquisition server, written for Century Aluminum in Kentucky. There are two major parts to this project: card drivers (for the PCL-711, ISO-813, and DIO-144 analog/digital I/O cards), and a master server that collects data from the cards and puts it into shared memory.

Several other utilities are discussed as well, such as showsamp, which gets the data from shared memory. This chapter is a good insight on how to handle I/O, as well as shared-memory management.

RAM-disk Filesystem

Many people want to write filesystems, or things that look like filesystems, for QNX Neutrino. The easiest filesystem to understand is a RAM-disk, because we don't need to deal with the “on-media” format—all of our data is stored in RAM, and the data itself is simply allocated from the pool of available memory. Reading, writing, seeking, block management, pathname parsing, directory management, etc. are discussed. This is an extensive chapter that serves as a foundation for the tar Filesystem Manager chapter (immediately following) and also serves as a good basis for any projects you may wish to pursue that need a filesystem (or a filesystem-like) interface.

TAR Filesystem

This chapter presents another filesystem, one that manages .tar files. It builds on the ideas and content of the RAM-disk chapter (above) and shows how to manage an indexed file—a virtual file that is hosted as a portion of a real, disk-based file.

Additional topics at the end give you some ideas of other types of filesystems that can be constructed.

References

Finally, the last section of the book contains appendixes with useful reference material, as well as some additional general topics:

Filesystems

This appendix provides additional information about the basics of filesystems, not only how files, directories, and symlinks are organized, but also how they map to the resource manager OCB and attributes structures. Fundamentally, all filesystems are a mapping between some physical (or abstract) hierarchical data representation onto the native resource manager structures.

The /proc Filesystem

The /proc filesystem is where QNX Neutrino stores all of the information about processes and threads — how much CPU time they've used, how much memory they have allocated, how many threads are running, what state they are in, etc. This appendix serves as a handy reference for the /proc filesystem, and shows you what information is available, where it is, and how to get it.

Sample Programs

This appendix tells you where to get an archive of the programs discussed in this book, and describes the contents and structure of the archive.

Glossary

Finally, you'll find a glossary that defines the terms used in this book.