Getting Started with QNX Neutrino - QNX Software Systems

QNX 4 and Neutrino
© 2009, QNX Software Systems GmbH & Co. KG.
Under Neutrino this was abstracted into an extension of the POSIX struct
sigevent data structure. Anything that used or returned the struct sigevent
structure can use a signal or a pulse.
In fact, this has been extended further, in that the struct sigevent can even cause
a thread to be created! We talked about this in the Clocks, Timers, and Getting a Kick
Every So Often chapter (under “Getting notified with a thread”).
Device driver model
MIPS, PPC, SH4, and ARM support
Under the previous-previous version of the operating system (the QNX 2 family),
writing device drivers was an arcane black art. Under QNX 4, it was initially a
mystery, but then eventually some samples appeared. Under Neutrino, there are books
and courses on the topic. As it turns out, the Neutrino model and the QNX 4 model
are, at the highest architectural level, reasonably similar. Whereas QNX 4 had
somewhat muddled concepts of what needed to be done as a “connect” function, and
what needed to be done as an “I/O” function, Neutrino has a very clear separation.
Also, under QNX 4, you (the device driver writer) were responsible for most of the
work — you’d supply the main message handling loop, you’d have to associate
context on each I/O message, and so on. Neutrino has simplified this greatly with the
resource manager library.
One of the driving changes behind the embeddability differences between QNX 4 and
Neutrino is the fact that Neutrino supports the MIPS, PowerPC, SH4, and ARM
processors. Whereas QNX 4 was initially “at home” on an IBM PC with a BIOS and
very standard hardware, Neutrino is equally at home on multiple processor platforms
with or without a BIOS (or ROM monitor), and with customized hardware chosen by
the manufacturer (often, it would appear, without regard for the requirements of the
OS). This means that the Neutrino kernel had to have provision for callouts, so you
could, for example, decide what kind of interrupt controller hardware you had, and,
without having to buy a source license for the operating system, run on that hardware.
A bunch of other changes you’ll notice when you port QNX 4 applications to
Neutrino, especially on these different processor platforms, is that they’re fussy about
alignment issues. You can’t access an N-byte object on anything other than an N-byte
multiple of an address. Under the x86 (with the alignment flag turned off), you could
access memory willy-nilly. By modifying your code to have properly aligned
structures (for non-x86 processors), you’ll also find that your code runs faster on x86,
because the x86 processor can access aligned data faster.
Another thing that often comes to haunt people is the issue of big-endian versus
little-endian. The x86 processor is a mono-endian processor (meaning it has only one
“endian-ness”), and that’s little-endian. MIPS and PPC, for example, are bi-endian
processors (meaning that the processor can operate in either big-endian or little-endian
mode). Furthermore, these non-x86 processors are “RISC” (Reduced Instruction Set
CPU) machines, meaning that certain operations, such as a simple C language |=
(bitwise set operation) may or may not be performed in an atomic manner. This can
290 Appendix: A • QNX 4 to Neutrino April 30, 2009