A year and a half ago RIM jumped on the opportunity to purchase an OS vendor called QNX (pronounced Que-NIX, like UNIX with a Q in front). RIM saw a growing gap between its BlackBerry OS and what Apple/Google were working on and realized it needed something new to effectively keep up with the joneses. The age old debate between build vs. buy kicked in to high gear and RIM took the route with less internal risk: acquire QNX.
QNX's Neutrino 6.5 OS is the basis of the BlackBerry Tablet OS running on the PlayBook. QNX features a very small (by modern standards) microkernel of around 100K lines of code. By comparison the modern day Linux kernel is around 14M lines of code. QNX argues that by limiting the scope of the kernel it can ensure greater stability and less vulnerability to bugs in the code. QNX is functionally a modern OS, however everything beyond the base kernel is supplied in the form of separate, self contained services. Even drivers are excluded from the microkernel.
QNX is, as a result, a very modular operating system. Additional features are added simply by bundling extra services, however for specific markets you don't incur any complexity or security penalty as unneeded services are simply turned off.
Because it's so modular, QNX has no issues being used in everything from the PlayBook to high end Cisco routers. Obviously the requirements of a tablet are very different from a router, so RIM actually implemented an updated version of QNX 6.5 into the PlayBook with some tablet specific features. The QNX team worked on improving media playback and GPU performance in QNX, features that will eventually make their way into QNX 6.6.
Another benefit of the modularity of QNX is that each service runs effectively sandboxed. A crash within a single service won't bring down the whole OS. Restarting a single crashed service can be done quickly. A small kernel should also be able to boot quicker, however the PlayBook itself has a longer boot time than Honeycomb because the entire OS image is validated using a crytographic hash on boot up. As a result of this image validation, the PlayBook will always boot into a known secure environment. Should the image validation fail, the PlayBook will typically install a previous known-good copy of the kernel stored on a separate partition.
Communication between services/processes happens via a structured messaging system. This is of course one of the benefits of a microkernel OS: inter process communication is usually quite good, because it has to be.
In QNX every task or thread has a priority. While a handful of priorities are reserved for system level events (to prevent an app from taking priority over refreshing the screen for example), everything else is defined by the caller. QNX argues that unlike in monolithic non-realtime OSes, task/thread priorities are nearly always respected here. Inevitably you'll have a number of tasks that have the same priority, and there the scheduler will just round robin between them. The one guarantee QNX offers is that any task with a higher priority will execute in accordance with that priority. This is ultimately what makes QNX a realtime OS.
Large monolithic OSes often give you the same promises, however QNX argues that they don't always hold true to them. There's always some system process that's interrupting things or a runaway task that prevents your screen from updating as quickly as you need it to. These days with hefty multi-core CPU architectures, hiding scheduling latency due to a system process interrupting something else isn't too difficult. On tablets/smartphones it's more of a problem given limited CPU resources, but ultimately it'll diminish there as well. There is arguably a power efficiency benefit here but at a high level that's a difficult thing to measure.
The QNX OS itself has been ported to everything from x86 to PowerPC. Although the PlayBook uses an ARM based OMAP 4430 today, it looks like RIM is pretty open to moving to other microarchitectures should the need arise.
On the PlayBook RIM implements the latest version of the QNX file system. The setup supports 64-bit LBAs (effectively no limit on single file size given current NAND capacities) and 1K file names.
File system performance is difficult to measure at this point given that we're dealing with pretty low performance NAND as well in devices like the PlayBook.
ncG1vNJzZmivp6x7orrAp5utnZOde6S7zGiqoaenZIFzgpVomaWZk6Cvpr7RsmSppJGur7C7ymapnq6ZmsRwfw%3D%3D