Project: Linux Interviews

A talk with Paul Leroux

By Prakash Advani <Prakash@freeos.com>
Posted: ( 2001-06-14 08:29:52 EST by gatha )
Paul Leroux is a technology analyst with QNX Software Systems, where he has served in various roles since 1989. Paul undertakes research on OS architecture issues, with an emphasis on applications for information appliances and networking equipment. In this interview, he explains how QNX is different from other operating systems, how it compares with linux and talks about the company's future plans.

Who is the main brain behind the QNX kernel? We heard one of the key developers passed away?

There are, in fact, several "main brains" behind the kernel. Dan Dodge and Gord Bell are the original co-authors of the QNX RTOS and both are still involved in the design of our core products. However, we now have several senior architects (in addition to Dan and Gord) dedicated to evolving the kernel and other key components. In short, the QNX kernel is the product of a closely-knit team of architects, not just one person.

We did lose one of our early architects, Dan Hildebrand, to cancer in 1998. Dan was, among other things, the brains behind the now-famous QNX demo disk, which fits a POSIX RTOS, GUI, Web browser, Web server, TCP/IP - along with various games and demos - on a self-booting 1.44M floppy! Dan Hildebrand was a wonderful influence in this company, and still is today. As we mention in a biography published on our Website, Dan "saw possibilities where other people saw only problems." That attitude continues to inspire us.

What compelled you and your team to start QNX?

Dan Dodge and Gordon Bell first became interested in OS design as students at the University of Waterloo, where they worked on Thoth, one of the first OSs to use message passing. After completing their Masters degrees, Dan and Gord joined Bell Northern Research (now Nortel) as programmers - but continued to work together on message passing technology. Then, when the IBM PC was introduced, Dan and Gord saw an enormous market opportunity to start a company centered around their own message-passing OS - now known as QNX.

In the first phase of the company's history, Dan and Gord concentrated on RTOS technology that could enable standard PC hardware to work in factory robots, medical instruments, communication systems--virtually any application where reliability and performance were the key factors. In fact, QNX was the first PC OS to use microkernel architecture (1981), to support a hard disk (1982), to run in protected mode, to provide network-transparent distributed processing (1984), to provide built-in network fault-tolerance (1992), and to support a microkernel windowing system (1994). Not surprisingly, QNX became widely recognized, even among its competitors, as the leading RTOS for the PC/x86 platforms.

Then, in the late 1990s, we decided to take the same OS architecture that made QNX so successful on x86 and deploy that architecture on other platforms as well. As a result, the QNX RTOS now runs on PowerPC, MIPS, x86, SH-4, ARM, StrongARM, and, soon, XScale. Supporting these processors is enabling QNX to grow rapidly in previously untapped markets: routers, switches, in-car computers, etc.

How is QNX different than other operating systems? Is it based on a UNIX core?

Let me try to answer both these questions simultaneously. Like Solaris, Linux, and various other Unix-style OSs, the QNX RTOS is POSIX-compliant. As such, it lets you take advantage of an immense pool of source code and programming talent. Nonetheless, QNX's underlying architecture is completely different from Unix, and has been designed from the ground up for high-availability embedded systems - high-end routers and switches, for example.
For example, compared to a conventional Unix-style OS, the QNX RTOS can provide:

Higher availability and reliability: Instead of the monolithic architecture adopted by most Unix-style OSs, QNX uses a microkernel architecture in which every driver, protocol stack, Java VM, and OS module (e.g. file system) can run in the safety of its own memory-protected address space. As a result:
It's very difficult for any module, even a poorly written driver, to corrupt either the kernel or any other module. Faulty drivers, protocols, applications, etc. can be automatically stopped, and restarted, before they cause other services to fail.
Virtually any component of the system - be it a driver, protocol stack, OS module, or an application - can be upgraded dynamically; no need for user intervention or reboots. This makes software upgrades much simpler. In fact, many QNX systems run nonstop for years at a time, even though they are upgraded regularly with new file systems, drivers, etc (Refer to images given below).

Easier to scale: QNX also makes it easier to scale your systems, whether you are creating loosely coupled CPU clusters or tightly-coupled SMP systems. Either way, there's no need for special code:

Networked Clusters: The QNX RTOS is inherently network-distributed, so you can partition an application across any configuration of loosely coupled nodes, without need for network-specific code. Applications don't need to `know' whether they're talking to each other on the same processor or across the network; they simply pass messages to each other using standard POSIX functions, and the QNX C library takes care of the rest. This has some pretty interesting ramifications. For example, say you have a home network consisting of several connected appliances. If one appliance has an Internet connection or a Web browser or flash memory or an MP3 archive, whatever, then any other appliance could access that resource automatically. No user configuration or special networking code required.

SMP: With conventional Unix-style OS architecture, SMP often demands numerous performance-robbing modifications to drivers and kernel code. With QNX's microkernel architecture, however, SMP requires only a few tiny changes to the kernel. Better yet, all other multithreaded processes--drivers, applications, databases, file systems, etc--can gain the performance advantages of SMP without modifications. (Refer to image given below)

With QNX's microkernel architecture, drivers, protocol stacks, and OS modules can migrate from a single-CPU device to an SMP system - or be distributed across a network of loosely coupled devices - without recoding.

Easier driver development: With QNX's microkernel architecture, most OS-level services (drivers, file systems, and so on) exist as user programs that run outside the kernel, just like regular applications. As a result, developing drivers and OS extensions (e.g. custom file systems) doesn't require kernel programming or kernel debugging. Instead, you use standard source-level tools and techniques. Better yet, QNX lets you test changes in driver code without kernel rebuilds or system reboots: simply recompile and restart the driver. Great for productivity.

Lower memory costs: Because of the fine-grained scalability of microkernel architecture, the QNX RTOS can provide a runtime environment considerably smaller than traditional Unix-style OSs, a critical advantage in high-volume devices, where even a $2 reduction in memory costs per unit can return millions of dollar in profits. In fact, QNX's native windowing system, the QNX Photon microGUI, also uses a microkernel architecture, so designers can easily "unplug" GUI services that aren't required by their memory-constrained devices.

Realtime determinism: Unlike Unix or Linux, QNX was designed from the beginning for real time and has proven itself in thousands of hard realtime systems - nuclear power plants, medical instrumentation, factory robots, process control systems, emergency response systems, etc.

Where did QNX get its inspiration from?

Our customers! As realtime embedded developers, they need to create applications that are small, fast, reliable, predictable, and like everyone else, they're under incredible time-to-market pressures. They expect a lot from us, and that really keeps us on our toes. But just as important, our customers create very cool - and often very important - applications; everything from kidney dialysis machines and emergency response systems to network routers and Web tablets. It's very motivating when you know your technology will do everything from help save lives to make the Internet run better.

On what hardware platforms does QNX run?

Development environment: QNX's self-hosted development environment (i.e. the QNX realtime platform) runs on x86. You can also target QNX from Solaris, Linux, and Windows workstations.

Runtime environment: The QNX RTOS, which forms the core of the QNX realtime platform, runs on PowerPC, x86, MIPS, SH-4, ARM, StrongARM, and, soon, XScale targets.

One very nice thing about our processor support is that you can target multiple processors simultaneously, using a single stream of source code. In some cases, the developer simply needs to specify a new processor target to generate binaries for a different processor.

Traditionally, embedded developers have had to put in a lot of duplicate effort to target multiple processor families, since each processor can differ in how it handles memory alignment, atomic operations, byte ordering, and so on. But we've implemented a few simple functions and macros to address these issues, minimizing the need to rewrite and retest code for each CPU. This processor independence enables faster time-to-market, since programmers no longer have to wait for a target processor to be chosen before starting to write and debug their software. In fact, programmers can start much of their development and testing right on their x86-based QNX workstations, even if the target device doesn't eventually use an x86 processor.

Why did QNX decide to go Open Source?

The reason is -- because access to source code makes software developers happier and more productive. With source code, 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 - not only when problems occur in their own programs, but when a problem involves unexpected results from underlying OS code. In short, developers gain a level of vendor independence and self-sufficiency not possible with the "black box" model of many commercial OSs.

We are also going `open source' (actually, we tend to call it `accessible source' since we use a different source licensing model than the GPL) to help increase the number of available applications and device drivers for the QNX community. Speaking of drivers, we've recently released several new driver development kits (DDKs)--Graphics, Input, Printer, Networking, and USB--that are all available free of charge on the QNX Developer's Network, at qdn.qnx.com/ddks. Each QNX DDK comes complete with sample drivers, libraries, headers, and documentation.

Who was behind this decision?

Making our source available is a decision that we took as a company. Decision makers from all departments--R&D, marketing, sales, customer service, etc -- were involved.

Has the visibility of QNX increased since it went open source?

Our visibility has gone up immensely in the past eight months: over a million downloads of the QNX realtime platform since September 2000. But it's hard to tell how much of that visibility is due to our source model and how much is due to the fact that people are simply hungry for the kind of reliability, speed, and efficiency that the QNX OS can offer. There is no question, however, that the developer community has welcomed our accessible source model, and that it will continue to help increase our popularity.

Why is QNX not released under GPL?

The vast majority of QNX's core technology is wholly owned and authored by QNX, and the source that we provide is covered under our own licensing agreement, which gives developers the freedom to create derivative works without having to sacrifice any of their own intellectual property (IP). One reason we use our own license, and not the GPL, is that intellectual property is a huge issue for our embedded OEMs customers. Many won't even consider GPL. We need to provide them with a license that provides the productivity of open source, but that also accommodates their IP requirements.

What are the popular applications ported to QNX?

Remember that, because QNX conforms to POSIX and Unix standards, many Unix and Linux applications can port to QNX without little or no modification. For example, QNX can run Unix-based software like Apache, Perl, and GateD natively, without code changes.
Having said that, it's hard to know where to start. But let's see…
If you download the QNX realtime platform, you'll get:
Flash Player from Macromedia, RealPlayer from RealNetworks, ICA client from Citrix, RenderWare 3D toolkit from Criterion, and so on. You'll also get hundreds of POSIX and Unix utilities, from awk to zcat.

If you go to sites like tucows.com or qnxstart.com, you get:
ICQ client, IRC client, Napster client, Lynx browser, Lilliput, and many others.
Others I can think of include:
Opera web browser
FreeAmp MP3 player
REBOL/Core
VisualAge J9 virtual machine from IBM

How does QNX compare with Linux?

First of all, there's a lot of common ground. QNX and Linux share APIs, tools, etc. so that Linux developers can easily learn QNX, and vice versa. Actually, you can think of QNX and Linux as providing a very nice form of synergy. Together, they allow developers to leverage the same skill sets across a very wide spectrum of applications -- much wider, in fact, than any single operating system could do on its own.

Nonetheless, they are different. While they share programming interfaces, QNX is inherently realtime, whereas Linux is a general-purpose OS. QNX has a microkernel architecture (i.e. drivers, protocols, and file systems are dynamically upgradable, memory-protected processes), whereas Linux follows a far more traditional "monolithic" kernel architecture. I can name other differences (e.g. QNX is inherently network-distributed, QNX can scale smaller, etc.), but the point is that QNX and Linux are different tools suited to different jobs. For example, QNX is extremely well suited to the network-distributed architecture of a high-end router. It's also a superior choice for small, memory-constrained Web appliances or for any application that requires `hard' realtime determinism.

I'm only talking about technical merits here. But you also have to consider the company and people behind the QNX RTOS. We serve the embedded market, and embedding is hard stuff. OEMs building embedded products have very complex requirements and expect a phenomenal amount of expertise and experience on the part of their OS vendor. That's where we have a real edge, since we've been in the embedded business for over 20 years. We know the needs of embedded developers intimately.

How easy is it for Linux and Unix developers to develop applications on the QNX realtime platform?

Because QNX shares common APIs and GNU development tools with Linux and Unix, application developers familiar with these platforms can become productive almost immediately. For instance, QNX provides Linux-hosted GNU tools, so developers can create QNX-based realtime/embedded applications from the comfort of their existing Linux workstations. From the Linux/Unix developer's perspective, most things can remain the same--tools, APIs, and programming model.

Linux/Unix developers can also choose to work from within QNX's self-hosted development environment; that is, they can `live' in the QNX realtime platform. Most developers find this environment very familiar, since it shares common GNU tools with Linux, including a port of the popular DDD debugger.

Who are the customers using QNX?

After 20 years in the embedded business, QNX has accumulated an impressive roster of customers: ABB, Alcatel, Centigram, Cisco, IBM, Du Pont, Eastman Kodak, Ford Motor Company, General Electric Transportation, Motorola, New York Stock Exchange, Mitsubishi, Philips, Siemens, Sony, Texaco, to name a few. These companies are using QNX for TV broadcast automation, medical instrumentation, Internet appliances, security systems, networking equipment, robotic control, in fact, I believe that all of the robots in MIT's Artificial Intelligence Lab are now being built around the QNX OS.

We like to say that it's hard to go through a day without using QNX. When I get in my car and go to work here in Ottawa (and many other cities!), the traffic lights are controlled by QNX. If I buy gasoline (petrol) using my Visa credit card, a QNX-based system will process the online transaction. If I have my color film processed, its processed by a QNX-based film printer. If I drink a bottle of beer, there's a good chance the bottle has been inspected by a QNX-based system. If I turn on a light switch, the power station generating the electricity might be controlled by QNX. If I donate blood platelets, chances are the blood-collection machine runs on QNX. The same is true if I need kidney dialysis. If I turn on my television, the programs I watch are often controlled by a QNX-based broadcast automation system. In fact, some TVs even have QNX built in, so users can access the Web directly from their TV.

In short, most people are QNX users without even knowing it!

What are the future plans of QNX?

Wow, that's a pretty big question. Obviously, we will continue to help grow our developer community through vehicles such as the QNX Developers Network and through making more QNX technology available through our source code repository.

We will also continue to enhance our technology to address the massive scalability and high-availability demands of our netcomm customers (i.e. OEMs building high-end switches, routers, etc.). Also, we'll continue to partner with protocol vendors such as NetPlane, IP Infusion, and Trillium, who specialize in providing stacks for netcomm OEMs.

In addition, we're working very aggressively at providing QNX developers with an expanded toolset. We recently announced alliances with AMC (CodeTest in-circuit tools) and MetaWare (IDE, compiler, debugger). more such announcements are in the offing for the near future.

Expect to see QNX increase its presence in the in-car computing market. QNX already provides the foundation for Motorola's mobileGT in-car computing platform and, recently, Intel announced that it also will be working with QNX on in-car telematics applications. More here

And, of course, we will continue to enhance our offerings for Internet appliance/home gateway developers, by offering the latest multimedia players, time-to-market source kits, and so on.

(Graphics courtesy: QNX Software Systems)

Other articles by Prakash Advani

Current Rating: [ 8.7 / 10 ] Number of Times Rated: [ 142 ]

Contents Articles   Howtos   Interviews   News   Opinions   Reviews Comparison Links   Articles   Howtos   Interviews   Opinions   Reviews   Websites News

Linux About Linux

Print It! Printer Friendly Version