Using Posix-Based Rtos For Embedded Systems.pdf

QNX Software Systems Ltd.

175 Terence Matthews Crescent

Ottawa, Ontario, Canada, K2M 1W8

Voice: +1 613 591-0931 1 800 676-0566

Fax: +1 613 591-3579

Email: info@qnx.com

Web: www.qnx.com

Real Time or Real Linux?

A Realistic Alternative

Paul N. Leroux

Technology Analyst

QNX Software Systems Ltd.

paull@qnx.com

Abstract

Designers of embedded systems have become increasingly interested in the Linux operating

system, largely because of its open source model. But, as it turns out, the standard Linux kernel

can’t deliver the hard realtime capabilities such as predictable response times and microsecond

latencies — that a large number of embedded systems demand. Several products have emerged to

fill the Linux realtime gap, with mixed success. For instance, some vendors have taken a dual-

kernel approach that provides a fragile runtime environment for realtime tasks, while forcing

developers to write new drivers and system services — even when equivalent services already

exist for Linux. Meanwhile, others have proposed a “pure” Linux solution that, to be effective,

would require a rewrite of the Linux driver and virtual file system frameworks. In this paper, we

look at an alternate approach — using 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 Linux’s open source model. As an added benefit, this approach

allows embedded developers to enjoy OS services unavailable with either standard Linux or

realtime Linux extensions. To illustrate the viability of this approach, the paper ends with

examples of various Linux applications already ported QNX Neutrino, the POSIX-based RTOS

from QNX Software Systems.

Real Time or Real Linux? A Realistic Alternative

Filling the Realtime Gap

however, has emerged as the “standard.” In fact,

some approaches even deviate from the standard

Linux/POSIX programming model.

For the embedded systems designer, Linux poses a

dilemma. On the one hand, Linux lets the designer

leverage a large pool of developers, a rich legacy

of source code, and industry-standard POSIX APIs.

At the same time, the standard Linux kernel can’t

deliver the “hard” realtime capabilities such as

guaranteed response times and microsecond

latencies — that many embedded devices require.

Real Time Implemented

Outside of Linux

For instance, most vendors provide “realtime Linux”

— note the quotation marks — by running Linux as

a task on top of a realtime kernel (see Figure 1). Any

tasks that require deterministic scheduling also run in

this preemptible kernel, but at a higher priority than

Linux. These tasks can thus preempt Linux whenever

they need to execute and will yield the CPU to Linux

only when their work is done.

The reasons for this are rooted in Linux’s general-

purpose architecture. Take process scheduling, for

instance. Rather than use a preemptive priority-

based scheduler, as an RTOS would, Linux

implements a “fairness” policy so that every process

gets a reasonable opportunity to execute. As a result,

high-priority, time-critical processes can’t always

gain immediate access to the CPU. In fact, the OS

will sometimes interrupt a high-priority process to

give a lower-priority process a share of CPU time.

Dual-Kernel Model

User Applications

Also, the standard Linux kernel isn’t preemptible.

A high-priority process can never preempt a kernel

call, but must instead wait for the entire call to

complete — even if the call was invoked by the

lowest-priority process in the system. This makes it

difficult, if not impossible, to create a design where

critical events are consistently handled within short

(and predictable) timeframes.

IPC

Linux Kernel

Realtime Tasks

Realtime Kernel

Hardware

Mind you, it’s wrong to think that this scheduling

model constitutes a deficiency in Linux. The model

does very well, for instance, at achieving the high

overall throughput required by desktop and server

applications. It only falls short when forced into

deterministic environments that it wasn’t designed

for, such as network routers, factory robots, medical

instruments, and continuous media applications.

Figure 1 — In the dual-kernel model, Linux runs as the

lowest-priority task in a separate realtime kernel.

In this dual-kernel model, the realtime kernel

always gets first dibs on hardware interrupts. If an

interrupt is flagged for a realtime task, the kernel

will schedule that task to run. Otherwise, the kernel

will pass the interrupt to Linux for processing. The

nice thing here is that all this work is invisible to

applications running in the Linux environment —

except, of course, for the CPU cycles lost to the

realtime kernel and its tasks. Still, the approach has

several shortcomings:

Be that as it may, several products have emerged

with the aim of filling in Linux’s realtime gap.

Some of these represent the work of commercial

vendors. Others are open-source research projects.

Some are a combination of both. No approach,

Page 2

Real Time or Real Linux? A Realistic Alternative

Real Time or Real Linux? A Realistic Alternativ e

Duplicated coding efforts

Tasks running in the realtime kernel can’t make

full use of existing Linux system services — file

systems, networking, and so on. In fact, if a

realtime task calls out to Linux for any service,

it will be subject to the same preemption

problems that prohibit Linux processes from

behaving deterministically.

leverage Linux’s widely supported APIs must

instead choose between competing "standards."

No determinism for existing Linux

applications and drivers

Because Linux processes don’t run in the real-

time kernel, they don’t gain any deterministic

behavior. Instead, they continue to be scheduled

according to Linux’s fairness algorithm.

As a result, new drivers and system services

must be created specifically for the realtime

kernel — even when equivalent services already

exist for Linux. Since few such drivers are

available off the shelf, Linux developers must

typically write them from scratch, using an

unfamiliar API.

Limited design options

As mentioned, the APIs supported by the

realtime kernel provide only a subset of the

services provided by standard POSIX and Linux

APIs. Hence, developers have fewer design

options than they would with either Linux or a

mature RTOS.

Fragile execution environment

Tasks running in the realtime kernel don’t

benefit from the robust MMU-protected

environment that Linux provides for regular,

non-realtime processes. Instead, they run

unprotected in kernel space. Consequently, any

realtime task that contains a common coding

error, such as a corrupt C pointer, can easily

cause a fatal kernel fault. That’s a problem, since

most systems that need real time also demand a

very high degree of reliability.

“Pure” Realtime Linux?

Given the shortcomings of the dual-kernel approach,

wouldn’t it be better to make Linux itself realtime?

Apparently, this can’t be too hard to do, since at

least one vendor has claimed they have a pure Linux

kernel capable of supporting applications with

“realtime requirements.” In a nutshell, they made

the kernel preemptible by enabling Linux’s SMP

locking mechanisms to work on a single processor.

Limited portability

With the dual-kernel approach, realtime tasks

aren’t Linux processes at all, but threads and

signal handlers written to a small subset of the

POSIX API or, in some cases, a non-standard

API. Moving existing Linux code and

applications to the realtime environment

becomes difficult.

This approach has merit, since it allows developers

to use a standard Linux kernel and programming

model. And, like other common approaches to

making Linux more deterministic, such as adding

high-resolution timers, it helps address the low-

latency requirements of reactive, event-driven

systems. Unfortunately, such low-latency patches

don’t address the complexity of most realtime

environments, where realtime tasks span larger time

intervals and have more dependencies on system

services and other processes than do tasks in a

simple event-driven system.

To complicate matters, different implementa-

tions of the dual-kernel approach use different

APIs. Realtime tasks written for one vendor’s

realtime extensions may not run on another’s.

Embedded device manufacturers hoping to

For instance, in systems where realtime tasks

depend on services such as device drivers or file

systems, the problem of priority inversion would

Real Time or Real Linux? A Realistic Alternative

Page 3

Real Time or Real Linux? A Realistic Alternative

have to be addressed within the Linux driver and

virtual file system (VFS) models. This would

effectively require a rewrite of those frameworks —

and of all device drivers and file systems employing

them. Without these modifications, realtime tasks

could experience unpredictable delays when

blocked on a service. As a further problem, most

existing Linux drivers aren’t preemptible. Thus, to

ensure predictability, programmers would also have

to insert preemption points into every driver in the

system — something that few Linux developers

have experience doing.

Compatible to the core

How well does QNX Neutrino support the Linux

programming model? The answer lies, to a great

degree, in the POSIX APIs adopted by Linux.

Though rooted in Unix practice, these APIs were

defined by the POSIX working groups purely in

terms of “interface,” not “implementation.” Simply

put, the APIs aren’t tied to any OS or OS architec-

ture. As a result, an RTOS can support the same

POSIX APIs as Linux (along with various subtleties

of Linux compatibility) without adopting Linux’s

non-deterministic kernel.

In any case, it’s unclear which realtime modifica-

tions, if any, will eventually be integrated into the

standard Linux kernel. After all, most Linux-based

systems rely on the kernel’s current approach, which

sacrifices predictability to achieve higher overall

throughput. A more deterministic kernel — with its

attendant reduction in average response times —

may simply be out of step with what most Linux

developers want.

The QNX Neutrino RTOS supplies proof for this

implementation-independent approach: It offers

POSIX-compliant APIs, but implemented on a

realtime, microkernel architecture (see Figure 2).

Importantly, QNX doesn’t implement POSIX as an

add-on layer. Rather, the very core of the QNX

Neutrino RTOS — the QNX microkernel — was

designed from the beginning to support POSIX

realtime facilities, including threads. POSIX, and

hence Linux, compatibility runs deep.

The Best of Both Worlds

The QNX ® Neutrino ® represents an entirely different

and altogether more viable approach to the problems

we’ve been discussing. Instead of trying to make

developers squeeze predictable response times out

of Linux, QNX Neutrino offers a proven realtime

operating environment that:

Embedded Linux: a new definition

This issue of API compatibility is taking on surpris-

ing importance as OEMs attempt to use Linux in

QNX Microkernel Model

• allows Linux developers to keep their existing

APIs and programming model

Manager

File

System

Device

Driver

Message Passing

• addresses the shortcomings of realtime Linux

extensions through a much tougher runtime

model, greater design options, and a unified

environment for realtime and non-realtime

applications

Microkernel

POSIX

App

TCP/IP

Manager

Java

• maintains key benefits associated with Linux’s

open source model, such as easier trouble-

shooting and OS customization — in fact,

QNX Neutrino’s architecture offers distinct

advantages on both counts

Figure 2 — In QNX Neutrino, the 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.

Page 4

Real Time or Real Linux? A Realistic Alternative

Real Time or Real Linux? A Realistic Alternativ e

their embedded products. Until recently Linux was,

more than anything else, a unified community of

developers creating software for a relatively narrow

range of environments mostly web servers and

workstations based on x86 hardware. This common

focus meant that Linux developers could count on a

variety of benefits: binary compatibility, a consistent

OS kernel, a pool of readily adaptable source code,

and so on.

helped save the Unix world from fragmentation. In

fact, the ELC specification will be based on existing

POSIX standards, such as the POSIX 1003.1, which

the QNX Neutrino RTOS supports today. As a result,

the QNX Neutrino RTOS will inherently support

embedded Linux applications, while simultaneously

providing all of the benefits of a true RTOS designed

from the ground up for embedded systems (more on

these benefits later).

Unfortunately, no such common focus is possible

in the embedded market, for the simple reason that

embedded systems are so incredibly diverse. Most

are purpose-specific, requiring custom applications,

custom drivers, custom OS services, custom board

designs, and so on. In fact, the consequences of

adapting Linux to this diversity are fast becoming

obvious. Scores of embedded OEMs and developers

are now independently rolling their own Linux

kernels with the result that, instead of one Linux,

many non-standard and incompatible versions exist.

Fragmentation isn't a distant threat; it’s happening

today. 1

Inherently Open

Still, Linux compatibility is a red herring if an

RTOS doesn’t also address why most developers

consider Linux in the first place: the benefits of its

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 — 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.

There is, then, a need for a new lingua franca

among embedded Linux developers a way to

define “embedded Linux” that accommodates the

teeming diversity of the embedded market, while

providing a critical mass of portability and

interoperability. That’s exactly what the Embedded

Linux Consortium (ELC), a vendor-neutral trade

association dedicated to advancing Linux in

embedded markets, is now doing with its soon-to-

be-proposed ELC Platform Specification. This

specification will define embedded Linux in a new

way: as a set of APIs, along with a test suite to

measure conformance.

The QNX Neutrino RTOS offers these benefits

in two ways: 1) by using a highly extensible

microkernel architecture; and 2) by providing

customers with source code for drivers, libraries,

and BSPs, including well-documented driver

development kits for a variety of standard devices.

As a microkernel OS, QNX Neutrino is fundamen-

tally open to customization. Except for a few core

services (e.g. scheduling, timers, interrupt handling)

that reside in kernel space, most OS-level services —

drivers, file systems, protocol stacks, and so on —

exist as user-space applications outside the kernel. As

a result, developing custom drivers and application-

specific OS extensions doesn’t require specialized

kernel debuggers or kernel gurus. In fact, as user-

space programs, OS extensions become as easy to

develop as standard applications, since they can be

Truth is, this approach isn’t really new. The POSIX

specification did much the same thing when it

1 Fragmentation raises another issue: lower reliability. A key reason

why standard x86 Linux performs so reliably is that a large com-

munity of developers is continually locating and fixing problems in

the code. That benefit no longer applies when you deploy a custom

Linux kernel supported by only a few developers.

Real Time or Real Linux? A Realistic Alternative

Page 5

Plik z chomika:

Inne pliki z tego folderu:

Inne foldery tego chomika: