QNX Neutrino RTOS系统架构详解：微内核设计与开发者指南

需积分: 50 120 浏览量更新于2024-07-22 2 收藏 2.76MB PDF 举报

QNX实时操作系统系统结构详解 QNX®SoftwareDevelopmentPlatform 6.6是QNX公司提供的一款专为嵌入式和实时环境设计的操作系统平台。QNX Neutrino Real-Time Operating System (RTOS) 是其核心产品之一，它在设计上秉承了高度可扩展性和高效性的理念。这个文档主要从开发者的角度，深入剖析了QNX Neutrino RTOS 的系统架构和设计理念。首先，QNX Neutrino RTOS 的哲学在于提供一个嵌入式版的POSIX操作系统（Portable Operating System Interface for UNIX-like systems），这意味着它不仅兼容标准的POSIX接口，使得开发者能够利用已有的POSIX应用程序库，而且在资源受限的环境中保持高性能和低开销。这种设计极大地简化了移植和集成现有软件的过程。产品规模的灵活性是QNX Neutrino RTOS的一大特点，它能适应从小型设备到大型工业控制系统等多种应用场景，确保在各种硬件平台上都能发挥出稳定性能。采用微内核架构，将核心功能与可选服务模块分离，提高了系统的可靠性和稳定性，同时降低了复杂性。作为操作系统，QNX Neutrino被视为一个由多个独立进程组成的团队，每个进程拥有自己的内存空间和执行上下文，相互之间通过安全、高效的通信机制进行协作。这种设计使得系统的扩展性和隔离性得到增强，有助于构建安全、模块化的应用环境。系统中的关键进程包括内核服务进程、系统管理进程以及用户应用程序。内核负责基本的系统管理和资源管理，如内存管理、中断处理和定时器服务。系统管理进程负责监控和配置系统状态，而用户应用程序则是在这个平台上运行的实际任务执行者。 QNX Neutrino的通信机制主要依赖于其强大的 Inter-Process Communication (IPC) 功能，支持多种通信方式，如管道、消息队列、共享内存和信号量等，这些机制使得不同进程间的数据交换和同步变得灵活且高效。文档还强调了QNX Neutrino作为“mess”（即基石）的重要性，表明它不仅是应用开发的基础，也是整个系统运行的基石，支撑着复杂嵌入式系统的稳定运作。 QNX Neutrino RTOS凭借其POSIX兼容性、微内核设计、高度可扩展性和强大的IPC功能，成为嵌入式领域的重要解决方案，尤其适合对实时性和安全性有高要求的应用场景。这份指南提供了开发人员在使用QNX Neutrino时所需的关键信息，帮助他们充分利用这一操作系统的优势。

Why POSIX for embedded systems?

A common problem with realtime application development is that each realtime OS

tends to come equipped with its own proprietary API. In the absence of industry

standards, this isn't an unusual state for a competitive marketplace to evolve into,

since surveys of the realtime marketplace regularly show heavy use of in-house

proprietary operating systems. POSIX represents a chance to unify this marketplace.

Among the many POSIX standards, those of most interest to embedded systems

developers are:

• 1003.1—defines the API for process management, device I/O, filesystem I/O, and

basic IPC. This encompasses what might be described as the base functionality of

a UNIX OS, serving as a useful standard for many applications. From a C-language

programming perspective, ANSI X3J11 C is assumed as a starting point, and then

the various aspects of managing processes, files, and tty devices are detailed beyond

what ANSI C specifies.

• Realtime Extensions—defines a set of realtime extensions to the base 1003.1

standard. These extensions consist of semaphores, prioritized process scheduling,

realtime extensions to signals, high-resolution timer control, enhanced IPC

primitives, synchronous and asynchronous I/O, and a recommendation for realtime

contiguous file support.

• Threads—further extends the POSIX environment to include the creation and

management of multiple threads of execution within a given address space.

• Additional Realtime Extensions—defines further extensions to the realtime standard.

Facilities such as attaching interrupt handlers are described.

• Application Environment Profiles—defines several AEPs (Realtime AEP, Embedded

Systems AEP, etc.) of the POSIX environment to suit different embedded capability

sets. These profiles represent embedded OSs with/without filesystems and other

capabilities.

For information about the many POSIX drafts and standards, see the IEEE

website at http://www.ieee.org/.

Apart from any “bandwagon” motive for adopting industry standards, there are several

specific advantages to applying the POSIX standard to the embedded realtime

marketplace:

Multiple OS sources

Hardware manufacturers are loath to choose a single-sourced hardware

component because of the risks implied if that source discontinues

production. For the same reason, manufacturers shouldn't be tied to a

The Philosophy of the QNX Neutrino RTOS

Microkernel architecture

Buzzwords often fall in and out of fashion. Vendors tend to enthusiastically apply the

buzzwords of the day to their products, whether the terms actually fit or not.

The term “microkernel” has become fashionable. Although many new operating systems

are said to be “microkernels” (or even “nanokernels”), the term may not mean very

much without a clear definition.

Let's try to define the term. A microkernel OS is structured as a tiny kernel that provides

the minimal services used by a team of optional cooperating processes, which in turn

provide the higher-level OS functionality. The microkernel itself lacks filesystems and

many other services normally expected of an OS; those services are provided by optional

processes.

The real goal in designing a microkernel OS is not simply to “make it small.” A

microkernel OS embodies a fundamental change in the approach to delivering OS

functionality. Modularity is the key, size is but a side effect. To call any kernel a

“microkernel” simply because it happens to be small would miss the point entirely.

Since the IPC services provided by the microkernel are used to “glue” the OS itself

together, the performance and flexibility of those services govern the performance of

the resulting OS. With the exception of those IPC services, a microkernel is roughly

comparable to a realtime executive, both in terms of the services provided and in their

realtime performance.

The microkernel differs from an executive in how the IPC services are used to extend

the functionality of the kernel with additional, service-providing processes. Since the

OS is implemented as a team of cooperating processes managed by the microkernel,

user-written processes can serve both as applications and as processes that extend

the underlying OS functionality for industry-specific applications. The OS itself becomes

“open” and easily extensible. Moreover, user-written extensions to the OS won't affect

the fundamental reliability of the core OS.

A difficulty for many realtime executives implementing the POSIX 1003.1 standard

is that their runtime environment is typically a single-process, multiple-threaded model,

with unprotected memory between threads. Such an environment is only a subset of

the multi-process model that POSIX assumes; it cannot support the fork() function.

In contrast, QNX Neutrino fully utilizes an MMU to deliver the complete POSIX process

model in a protected environment.

As the following diagrams show, a true microkernel offers complete memory protection,

not only for user applications, but also for OS components (device drivers, filesystems,

etc.):

Microkernel architecture

剩余323页未读，继续阅读

qq_22084221

粉丝: 1
资源: 1

QNX Neutrino RTOS系统架构详解：微内核设计与开发者指南

QNX Persistent Publish/Subscribe Developer's Guide

STM32F103C8T6+FreeRTOS+Keil5 代码（亲测完美）

QNX\QNX_Momentics_IDE_使用方法

分布式嵌入式实时操作系统qnx pdf

分布式嵌入式实时操作系统 qnx_侯业

qnx系统内核接口文档

linux系统和qnx系统有什么区别？

qnx开发手册(1.1版).pdf

qnx 开发手册 pdf

qnx和linux区别

最新资源