Getting Started with QNX Neutrino - QNX Software Systems

© 2009, QNX Software Systems GmbH & Co. KG.
When I found myself staring at the first draft of this book I started thinking that it was
going to be a difficult read because I’d spent so many years intimately involved with
the design and development of QNX Neutrino. But I was wrong! I found this book
easy to read and very enjoyable because of the way Rob combines the QNX
philosophy (“Why things are the way they are”) with good habits applicable to any
realtime programming project. This book is suitable for people who’ve never seen
Neutrino before, or those who’ve used it extensively.
For people who’ve never used Neutrino, the book gives an excellent tutorial on how to
use it. Since Rob himself comes from a QNX 2 and QNX 4 background, his book is
also great for people who’ve used a QNX operating system before, because they share
a common ground.
As for myself, I was first introduced to QNX at an insurance company in the
mid-1980s. This insurance company primarily used an IBM mainframe, but they
wanted to shorten the time required to calculate quotes on corporate insurance. To do
this they used networks of 8 MHz 80286 ATs running QNX 2. They distributed their
data using QNX native networking, allowing access to all customer data files from any
QNX machine. This system was well-designed using the QNX client/server
philosophy and I was hooked on QNX.
When I joined QSS at the start of 1991, QNX 4 had just been released. QNX 4 was
developed to conform to the just-approved POSIX 1003.1 specification which would
make it easier to port public domain UNIX code than it was with QNX 2, and it would
conform to a genuine standard. In a few years we started thinking about the
next-generation operating system. The current group of less than 15 developers started
meeting to discuss anything we’d like to do differently and things that we’d need in the
future. We wanted to support the newer POSIX specifications and make it easier to
write drivers. We also didn’t want to lock ourselves to the x86 processor or “fix”
anything that wasn’t broken. The ideas that Dan Dodge and Gordon Bell started out
with when they created QNX are still in Neutrino today — ideas like message-passing,
having a small, lean kernel, providing fast, realtime response, etc. Complicating the
design was the goal of Neutrino being even more modular than QNX 4 (for example,
we wanted to provide a fully-functional kernel that you could link against, allowing
for more deeply embedded systems than QNX 4). In 1994 Dan Dodge and I started
working on the updated kernel and process manager.
As those of you who’ve been using QNX products for a long time already know,
writing device drivers for QNX 2 was a hair-raising experience. You had to be very
careful! In fact, most developers started with the QSS-supplied source for the spool
device and carefully tweaked it to do whatever they wanted. Only a few people tried
writing disk drivers, as this required specialized assembly language stubs. Because of
this, almost nobody ended up writing drivers for QNX 2. In QNX 4, writing drivers
was made much easier by making all I/O operations go through a standard,
well-defined, message-passing interface. When you did an open(), the server received
an open message. When you did a read(), the server received a read message. QNX 4
capitalized on the message passing theme by using it to decouple clients from servers.
I remember when I first saw the beta version 3.99 (a QNX 4 pre-release version) and
April 30, 2009 Foreword to the First Edition by Peter van der Veen 3