[G-bone]

Hey, fellow citizens of Crackberry Nation!
We've all been waiting a long time for BB 10...since the day we first heard BlackBerry acquired QNX.
Now, I would have to consider Linux superior (although a security nightmare on Android ) to Apple or Microsoft. And I have always considered QNX to be the most elegant awesomeness of all!
So,while we wile away the hours until The 10, and with the news/rumour that QNX is upgrading the QNX Neutrino kernel to 8.0, I found this great article re: QNX vs. Linux.
It's 3 years old, and a bit of a deep dive, but well worth the read, as we look into the heart of BB 10.
Remember, the release is just the beginning - after that it all just picks up speed..Embedded Development - QNX* or Linux*?
Submitted by (not verified) on Mon, 03/09/2009 - 16:40


Categories: Open Source
*

Introduction
By: Thomas W. Burger

In the late 1990�s, the Web appliance was touted as the next �big thing�, a new device for an emerging market that would create a next generation of consumer IT giants. At the Consumer Electronics Show in Las Vegas, Nevada and the QNX 2000 International Technology Conference in Vancouver, British Columbia many vendors, large and small, showed off multiple visions of the future.

Intel built a Web appliance based on Linux*. Microsoft partners made Web Companions based on a scaled down version of the Windows* CE operating system. Many others, like 3Com�s prototype and the Netpliance iOpener*, were based on QNX*. At that time Web appliances seemed the likely next step in consumer electronics. Simpler than PCs, they also offered far less functionality. At best they could be considered, as Ken Kalinoski, VP of development at Netpliance called it, a �Rich Client� device that required a dedicated and proprietary server to connect to. The subsequent lack of Web appliances on the shelves of Best Buy and Walmart showed that consumers did not want an appliance that could browse the Web and perform simple email tasks but could not do even simple word processing or store data. Web devices were being sold at less than cost in anticipation of service revenues that never came. Consumers also did not like the idea of being tied to a specific service provider.

Linux and QNX gained notoriety because of the obvious potential for both as the operating systems and development platforms for Web appliances. Linux had mostly been used as a server OS and QNX mainly as an industrial embedded Real Time Operating System (RTOS).To exploit this new market, many developers discovered the capabilities of Linux and QNX in developing smaller, more capable portable devices.

In hindsight, the Web appliance was an idea ahead of technology. There was the software and engineering talent available to produce these devices, but not the hardware and infrastructure to allow the functionality, versatility, and portability required to make the Web appliance the new must-have tech-toy. Advances in cell phone and PDA technology, improvements to digital cameras, lower power requirements, and greater memory capacities, far greater embedded/mobile CPU speeds, and, possibly the most important factor, 802.11b and 802.11g WiFi wireless networking has the Web appliance resurrected as a multifunction device. This combines a computer, organizer, office software suite, cell phone, camera (still and movie), pager, music player, and, of course, email system and Web browser into a single wireless unit that fits in a pocket.

Four years later, an eternity in technology terms, we are on the verge of a new �Next Big Thing�. Advances in hardware and in-place wireless and service infrastructure for the already enormous PDA and Internet capable cellphone market has created a great demand for devices that can do more, are more compact and have longer battery life. This has renewed interest in embedded development platforms that can provide the requirements necessary to compete in a market that is worth billions of dollars.

This is where the design similarities end. Linus Torvalds designed Linux to run on a standard PC hardware as a generalized OS using a monolithic kernel archi tecture. The kernel contains almost all of the functionality of the entire OS. In contrast QNX was designed to be extremely modular and scalable. QNX is a realtime operating system based on a microkernel - small enough to be embedded on a chip but capable of running a workstation or a large networked server system.

Linux for Embedded Development
Designers of embedded systems have long used the Linux operating system, because of its robustness, relative compactness, versatility, low cost, and open source licensing model. Linux lets the designer leverage a large pool of developers, a rich legacy of source code, and industry-standard Portable Operating System Interface (POSIX) APIs.

The standard Linux kernel does not have realtime capabilities (predictable response times and microsecond latencies, often referred to as deterministic behavior) that many embedded systems demand such as fly-by-wire controls, ABS braking systems, continuous media, and medical devices. But, Linux can be used as is in consumer devices that are not subject to deterministic issues. In order to provide for the requirements of embedded devices now being developed, where more predictable speed and timing behaviors are required, several Linux products have emerged.

Using Linux in an Embedded System
Although Linux was designed to run PC platforms, Linux can be a reliable OS for embedded systems. The typical shrink-wrapped Linux system has a full featured Linux kernel that requires about 1 MB of memory. The Linux �pure� kernel (virtual memory and all core operating system functions) actually consumes only about 100K. With the networking stack and basic utilities, a complete Linux system runs in about 500K of memory. The total memory required is dictated by the applications to be run, but a Linux system can be adapted to work with as little as 256 KB ROM and 512 KB RAM. So it's a lightweight operating system to bring to the embedded market.

Another benefit of using an open source Linux over a traditional RTOS is that the Linux development community tends to support new protocols faster and more device drivers than RTOS vendors do.

The core Linux operating system itself has a fairly simple microkernel architecture. Networking and file systems are layered on top of the microkernel in a modular fashion. Drivers and other features can either be compiled in or added to the kernel at run-time as loadable modules. This provides a highly modular building-block approach to constructing a customized embedded system, which typically uses a combination of custom drivers and application programs to provide the added functionality.

An embedded system also often requires generic capabilities, which, in order to avoid re-inventing the wheel, are built with off-the-shelf programs and drivers, many of which are available for common peripherals and applications. Linux can run on most microprocessors with a wide range of peripherals and has a ready inventory of off-the-shelf applications.

Linux is also well-suited for embedded Internet devices, because of its support of multiprocessor systems, which lends it scalability. This capability gives a designer the option of running a r ealtime application on a dual processor system, increasing the total processing power. So you can run a Linux system on one processor while running a GUI, for example, simultaneously on another processor.

A disadvantage to running Linux on an embedded system is that the Linux architecture can not provide realtime performance in its standard form. For instance, standard Linux has tasks scheduled according to a fairness algorithm that gives an equal share of processor time to each task. The solution is to modify Linux to behave in a deterministic manner through the addition of realtime changes in one of following methods:

The first solution is to add software modules that run in the kernel space, the portion of the operating system that implements the scheduling policy, hardware-interrupts exceptions and program execution. Since these realtime software modules run in the kernel space, a code error can impact the entire system's reliability by crashing the operating system.
The second solution, illustrated in Figure 1.,is the dual-kernel approach that provides a runtime environment for realtime tasks. This approach requires developers to write new drivers and system services although equivalent services already exist in the standard Linux kernel. This RTOS solution can slow load time and the increase size of the OS footprint.



Figure 1 - Linux with Dual Standard and RTOS Kernel
The third solution is that other embedded Linux vendors use a kernel rewritten to provide RTOS functionality by rewriting portions of the code, such as the scheduler, to be deterministic in behavior.
*

Standardization of Embedded Linux
There are over 200 distributions of Linux and many embedded versions. Without the existence of a standard for embedded Linux, so that a single unified platform specification can enable the use of a cost-effective, focused environment, Linux could be all but useless.

In order to make embedded Linux versions compatible the Embedded Linux Consortium (ELC) was formed. ELC is a nonprofit, trade association for the advancement, promotion and standardization of Linux throughout the embedded computing market. Members participate in management, promotion, implementation, and platform specification working groups in order to enjoy the benefits that standardization brings.

The ELC mission statement is �...to make Linux a top operating system choice for developers designing embedded systems.� Dr. Inder Singh, ELC Chairman and CEO of LynuxWorks commented �Linux is rapidly becoming the leading choice for the operating system for consumer electronic products, which are being designed with more and more embedded software."

Karen Chupka, vice president of events and conferences for the Consumer Electronics Association states, �Operating system software is a critical consideration for a rapidly growing list of consumer electronic products. Linux is destined for growth in 2004��

More than 75 companies have now joined the Consumer Electronics Linux Forum (CELF), formed by Sony and Matsu****a, to promote Linux-based digital CE products. Some of the other CE companies involved in the forum, officially launched in June of 2003, are NEC, Hitachi, Royal Philips, Samsung, Sharp and Toshiba.

Three Embedded Linux Versions
MontaVista Consumer Electronics Edition 3.0

MontaVista has introduced a version of its embedded Linux platform for consumer electronics devices. MontaVista �Consumer Electronics Edition 3.0� * (CEE*) is an embedded OS. It is aimed at applications such as mobile phones, digital TVs, set-top boxes, and automotive telematics. CEE is designed for highly constrained mobile devices that require low power consumption, restricted memory size and short boot and resume times. It is claimed to be the first commercial, embedded Linux distribution specifically designed for the consumer electronics market,

CEE supports dynamic power management features, file system enhancements, and tools to measure performance, system timing, memory size, and supports streaming media optimizations.

CEE features include:

Royalty-free Linux-based embedded OS and development environment
Consumer-grade reliability
Preemptible kernel technology and realtime scheduler
Dynamic Power Management* optimizes power usage, extending battery life
Rapid boot time for the kernel
File system enhancements - including support for streaming media optimizations
eXecute In Place (XIP) delivers fastboot, stand-by and resume features
Scalable memory footprint accommodates a range of consumer products
�Gold-standard� networking enables high-performance connected applications
Graphical MontaVista System Measurement Tool facilitates consumer-grade performance tuning
Optional pre-integrated Java* and graphics development and runtime product offerings
Supported by a wide array of commercial and open-source applications and middleware

LynxOS

Embedded software house LynuxWorks built two embedded Linux OS versions. LynxOS, a �Hard� RTOS embedded system, is shown in Figure 2. The LynxOS offers itself as a Linux RTOS that is Linus ABI compatible and in conformance with POSIX.* Being a microkernel design, the kernel footprint is small - only 28 kilobytes in size.
*


Figure 2 - LynxOS Architecture

The small kernel provides essential services including scheduling, interrupt dispatching, and synchronization. Other services are provided by kernel lightweight service modules, called Kernel Plug-Ins (KPIs). New KPIs can be added to the microkernel and can be configured to support I/O, file systems, TCP/IP, streams, and sockets. KPIs are multi-threaded, which means each KPI can create as many threads as it requires.

There is no context switch when sending a message to a KPI. For example, when a Request for Service (RFS) message is sent to a File System KPI, this does not request a context switch. Th is reduces the run-time overhead. Inter KPI communication creates minimal overhead with it consuming only very few instructions

Applications make I/O requests to I/O system through system calls. The kernel directs the I/O request to the device driver. Each device driver has an interrupt handler and kernel thread. The interrupt handler carries the first step of interrupt handling. If it does not complete the processing, it sets an asynchronous trap to the kernel. Later, when the kernel can respond to the software interrupt, it schedules an instance of the kernel thread to complete the interrupt processing.

BlueCat

The second embedded Linux OS version built by LynuxWorks is BlueCat* Linux for non-RTOS embedded use. BlueCat is not an RTOS, but is binary compatible with LynxOS allowing easy migration to RTOS, for embedded applications. BlueCat is designed specifically for use in embedded systems that do not have any requirement of an RTOS.

QNX
QNX is a POSIX-based RTOS designed specifically for embedded systems - that not only allows Linux developers to keep their programming model, but also maintains the key advantages of the Linux open source model. As an added benefit, this approach allows embedded developers to enjoy OS services unavailable with either the standard Linux or realtime Linux extensions. Figure 3 demonstrates the QNX architecture.*



Figure 3 - QNX Architecture

The QNX operating system is a private product by QNX Software Systems Ltd. (www.qnx.com*), Kanata, Ont. Like Linux, the basic design of QNX is derived from UNIX* developed in the 1970s by AT&T Bell Labs. Both QNX and Linux adhere to the LINUX POSIX standards.

The QNX Neutrino* microkernel offers a unified environment for realtime and non-realtime applications. The QNX Neutrino RTOS offers POSIX-compliant APIs, but implemented on a realtime, microkernel architecture (see Figure 3). The Neutrino microkernel contains only the most fundamental OS services. All other services are provided through optional, memory protected processes that can be stopped and started dynamically. To achieve this modularity, QNX Neutrino uses message passing as the fundamental means of IPC for the entire system.

Unlike Linux, QNX does not implement POSIX as an add-on layer. The QNX microkernel was designed from the beginning to support POSIX realtime facilities, including threads. The ELC specification will be based on the existing POSIX 1003.1 standard, which the QNX Neutrino RTOS supports. As a result, the QNX Neutrino RTOS will inherently support embedded Linux applications.

QNX, like Linux, provides the benefits of an open source model. With open source, developers can analyze the architecture of the OS to better integrate their own code, adapt OS components to application-specific demands, and save considerable time troubleshooting. QNX offers the above benefits in the following methods:

By using highly extensible microkernel architecture.
By providing customers with source code for drivers, libraries, and development Board Support Package (BSPs), including well-documented driver development kits for a variety of standard devices.

As a microkernel OS, QNX Neutrino is fundamentally open to customization. This is because most OS-level service drivers, file systems, and protocol stacks exist as user-space applications outside the kernel, except for a few core services (e.g. scheduling, timers, interrupt handling) that reside in the kernel space. As a result, developing custom drivers and applications specific OS extensions does not require specialized kernel debuggers or kernel gurus. In fact, as userspace programs, OS extensions become as easy to develop as standard applications, since they can be debugged with standard, source-level tools familiar to every developer.

QNX Neutrino allows applications to access all drivers and OS services through a single, consistent form of IPC, called synchronous message passing. This approach offers several advantages. For instance, as QNX message passing is synchronous, it automatically coordinates the execution of communicating programs. Thereby eliminating the need to handcode and debug complex synchronization services in every process (see Figure 3). Moreover, message passing inherently simplifies the task of partitioning a complex system into well-defined building blocks that can be developed, tested, and maintained individually. This works by having any service-providing program �advertising� its services to other programs by registering a pathname in the pathname space. Programs can then access those services by issuing calls such as open(), read(), write(), or lseek() on the pathname.

For example, the QNX serial-port driver typically registers the pathname /dev/ser1 to represent the first serial port. Any application that needs to access that port issues an open() function on /dev/ser1. For the application, the open() function behaves like a standard POSIX call. The QNX Neutrino C library converts the call into an io_open message and forwards the message to the serial driver. If the application subsequently wrote a character to the serial port, the following sequence occurs: the client would issue a write() function, the C library would then construct an io_write message, and the message would be sent to the driver.

The beneficial side effect is that the exact message can be sent from any client application to any service, provided the service supports that particular function. For instance, to write a character to a serial port or to put a character into a disk file, an application would issue the same write() function in either case; the only difference would be where the message was sent. This means the application is decoupled from the services it relies on. Decoupling simplifies development since all interactions between applications and system services can be implemented using a simple, POSIX-based programming model.

This eases code migration to new designs since applications don't have to include hardware or protocol specific code.

QNX Neutrino further simplifies troubleshooting and OS customization by providing customers with the source code for libraries, drivers, and BSPs. Developers can also freely download device driver kits (DDKs), which* include documentation and a software framework that implements all higher-level, device indepen dent code in libraries. The developer has to only write the hardware-specific code for the chip on their device.

QNX source code is not provided under the GPL that covers most Linux source. Rather, QNX Software Systems provides the source under its own license agreement, which, unlike the GPL, gives developers the freedom to create derivative works without having to forgo intellectual property (IP) rights.

As a monolithic OS, Linux binds most drivers, file systems, and protocol stacks to the OS kernel. Hence, a single programming error in any of these components can cause a fatal kernel fault. In QNX Neutrino, these components can all run in separate, memory-protected address spaces, making it very difficult for them to corrupt the kernel, or each other. QNX Neutrino therefore provides an environment for realtime applications that is inherently more robust than Linux and certainly much tougher than the unprotected realtime kernels used in the dual kernel approach.

QNX Added Value

QNX Neutrino provides the QNX micro network service that allows messages to flow transparently across processor boundaries. This means any process can access virtually any resource on any other network node as if it were local. If the pathname for the driver is local, the QNX microkernel will route the message directly; if the driver is on a remote node, the QNX micro network will transparently forward the message to that node.
Network traffic can also be load-balanced over all available links, resulting in higher throughput. This service is built-in; applications do not require any special networking code.
The fine-grained scalability of QNX microkernel architecture allows a runtime environment that can be considerably smaller than Linux.
The Photon microGUI*, also uses the microkernel architecture. Hence, designers can easily �unplug� GUI services that are not required by memory constrained devices.
QNX supports TCP/IP, NFS, and the Linux file system. So a development shop that uses a mix of Linux and QNX workstations can share resources across the two environments. In short, Linux and QNX Neutrino do more than simply coexist. Rather, they give developers the opportunity to leverage many of the same APIs, source code, and skill sets across a much wider spectrum of applications than any operating system whether realtime or general-purpose.
QNX supports MIPS, PowerPC, SH4, StrongArm, xScale, and x86 hardware. It is scalable from constrained embedded to multiprocessor platforms. The architecture provides multitasking, priority-driven pre-emptive scheduling, synchronization, and TCP/IP protocol. Utilities including PPP, DHCP, NFS, RPC, and SNMP are provided as well.
QNX has native message-based networking called Qnet.
The Photon microGUI windowing system is a GUI with a small memory footprint.
For GUI applications, there is also an integrated development environment called Photon Application Builder (PhAB), which unlike Visual Basic has drag-and-drop controls.
Self-hosting capabilities that simplify development.
QNX uses a version of the GNU GCC compiler.
QNX RTP supports C and C++ with the GCC-2.95. Also, qcc that is the front-end to GCC provides an abstract layer to mask the differences between the various compilers (GNU GCC, Watcom, and Metrowerks). There is also cc front-end, which is used to mask the differences between available compilers. This front-end also invokes the appropriate compiler (C or C++) based on file extensions. Currently it invokes GCC/G++. For project code management, the make, CVS, and RCS utilities are part of this QNX distribution.
There is a cross-compiler version of the GCC compiler that allows development on Windows for a Neutrino target.
*

Conclusion
In QNX, the realtime and non-realtime environments are the same. Realtime applications can take advantage of the full POSIX API and enjoy full access to system services. Existing POSIX/Linux applications can immediately gain deterministic behavior. And since both realtime and non-realtime applications are running in the same message-based environment, the IPC between them is greatly simplified. Less duplicated effort. As discussed, the dual-kernel approach can force developers to write custom drivers, using an unfamiliar API. As in most OS environments, developing these drivers requires kernel debugging tools (hard to use), kernel rebuilds (time-consuming), and kernel programmers (expensive). QNX Neutrino addresses this problem in several ways. First, like any established OS with a large user base, QNX supports a variety of off-the-shelf drivers for standard hardware. And, as we�ve seen, QNX Neutrino runs all drivers in user space, so they can be developed using standard source-level tools and techniques. This job is made easier by the QNX DDKs, which provide documentation, libraries, headers, and ready-to-customize source for a variety of drivers. Additional Microkernel Features, as a microkernel RTOS is designed specifically for the demands of embedded systems, QNX Neutrino also offers Linux developers features unavailable with either standard Linux or realtime Linux extensions.

Linux offers a greater developer base, software base and true open source code, as well as a larger platform base than QNX.* ELC and CELF are making embedded Linux standardized. The latest versions of embedded Linux claim hard RTOS with full POSIX compliancehttp://software.intel.com/en-us/articles/embedded-development-qnx-or-linux/

[nyplaya610]

Thanks for this! This was a great read.

[G-bone]

Thanks. Glad you liked it. I think, and have thought for some time, that QNX is the future.
#BB10Believe

[GTiLeo]

this is an Intel article correct? i haven't read through it yet but the beginning looks like the one i read and posted as an example about a month or so a go, its a good read and very informative

[G-bone]

Oh! Well, crap. Didn't mean to repost. I gotta agree - it is very informative. Wish I'd seen it the first time...

[GTiLeo]

not a repost it was in another thread dscussing QNX i doubt many were able to see it or even noticed it was there.

what i liek about QNX is its flexability and its developer relations stratagy, its somehting i believe they brought to the table with RIMs development of dev tools. coding in any laguage makes things easy and there is always help from the developer relations team

[jasonvan9]

"As a monolithic OS, Linux binds most drivers, file systems, and protocol stacks to the OS kernel. Hence, a single programming error in any of these components can cause a fatal kernel fault. In QNX Neutrino, these components can all run in separate, memory-protected address spaces, making it very difficult for them to corrupt the kernel, or each other. QNX Neutrino therefore provides an environment for realtime applications that is inherently more robust than Linux and certainly much tougher than the unprotected realtime kernels used in the dual kernel approach."

This is the paragraph that people should read when questioning the reliability of QNX vs. another OS or BBOS7.... in basic terms, this means no more spinning clocks, random freezes, unannounced restarts, complete system failures.... THIS is what im looking forward to, not Netflix, not Skype... the complete and utter satisfaction of knowing if im gone somewhere for work, that my phone will be working 100% of the time, keeping me connected to everything i need and everyone i love.