分享

 QNX/Neutrino    vs.   FSMLab/RTCore   Comparison
     –Microkernel vs. Real-time Extension

Huailin Chen,  November, 2004

中文前言：

这是笔者2004年10，11月左右写的一个关于Neutrino微内核与RTCore等技术的比较。现在整理并发表于此。由于时间的关系，不能将其翻译成中文了。请读者见谅。文章主要从体系结构，系统性能，编程模型，内存管理与保护和可移植性等方面来阐述。

四年过去了，QNX，FSMLAB也经历了许多变化。都被别的公司收购了。总体而言，我个人比较喜欢微内核技术。当然微内核有其自己的局限性。这需要在实际的工作中，按照系统的要求，去对微内核进行修改，裁剪和调试。任何一个操作系统都是为应用服务的。所以设计系统的关键还是应用决定下面的需求。
0. Architecture

–Neutrino ( www.qnx.com ) is a micro-kernel. It can exist alone without any dependent packages. For being a micro-kernel, like CMU’s Mach, Andrew T. ‘s Amoeba as well as Minix and L4, these following components must be provided: Process/Thread Management; Memory Management; Exception Handling; Message-Passing Interface.

–RTCore (www.fsmlabs.com ) is designed to provide better real-time services for traditional time-sharing based monolithic operating system, alleviating the pains of kernel non-preemption and non-deterministic interrupt latency.

–RTAI/Adeos ( www.rtai.org ) provides similar technology as RTLinux does.

            –RTAI supports x86, PPC, ARM and MIPS

–RTAI is FREE and Open Source

– With latest Linux 2.6 addition, the kernel preemption patchis officially on. Linux can support better performance towards hard real-time requirements. However, Linux is yet able to be claimed as a real real-time operating system.

– With RTCore or RTAI, it does provide less interrupt latency, for instance, 5us per RTCore technology claims.

–RTCore is a real-time extension/patch for Linux initially and is ported to BSD community recent years. It is not a micro-kernel from both conceptual and technical viewpoint.
–RTCore is a loadable kernel module(LKM) for Linux kernel. It’s a part of Linux kernel codes/package after being installed.

–RTCore itself is not able to exist if without the “Secondary OS” .

–RTCore itself does NOT provide enough, if not at all, memory management, a message-passing interface. It relies on the BSD/Linux kernel to provide so. In other words, from system architecture viewpoint, RTCore/RTAI technology is “tightly coupled” with BSD/Linux kernel.

1. Performance

–Neutrino claims the support of real-time computing with micro-kernel preemption, flexible share memory mechanism and high performance message passing. From benchmark data released from QNX Inc, neutrino’s context switch and interrupt latency all range within micro-seconds. Note that, usually we believe message-passing model is very time-cost when compared to system call interface with a tradtional monolithic OS model, for example, Linux/BSD

–Neutrino provides system scope real-time scheduling based on process/thread priorities. A system could provide fine-granularity real-time services to a wide range of real-time computing applications

–RTCore, adding codes into Linux/BSD kernel scheduler as well as interrupt handler parts, can provide very good real-time response to both interrupt handing and real-time task processing applications.

–RTCore does not provide real-time services to the Liux/BSD normal applications. Iff (If and ONLY if) there exists real-time RTCore threads, RTCore scheduler will never transfers the CPU to Linux/BSD user level processes/threads. This coarse granularity real-time computing model does introduce starvations into a realtime system. For example, a real-time application(BGP Daemon) may have to reside in Linux/BSD user level side.

2. Programming Model

–Neutrino supports full POSIX 1, POSIX 1.B, POSIX 1.C and a native message-passing mechanism/interface. It provides a very good and consistent programming model.

–Neutrino does not seamlessly support gcc tool-chain programming environment, but qcc, which is built on top of gcc.

–Applications on top of Neutrino are exactly same as what we did when under a UNIX machine.  Unix developers should be very easy to migrate into QNX/Neutrino world. However, writing device drivers for Neutrino is an exception. The Resource Manager Concepts and mechanisms are new to lots of people from Linux/BSD side.)

–RTCore support POSIX PE51, only providing a very basic set of real-time primitives, compared to Neutrino.  Please note that RTCore programming API is not POSIX API compatible; its API is more POSIX-like. RTCore threads MUST not able to call a BSD/Linux part block mode primitives or system calls (when RTCore threads run in user mode.). Therefore, any POSIX library Linux/BSD provides are not able to be used directly by RTCore real-time applications.

–RTCore, as a LKM module within Linux/BSD, supports gcc tool-chain seamlessly.

–Applications of RTCore either need developers able to have Linux/BSD kernel-programming (when write in-kernel RTCore threads) skills. Also, developers should be very clearly aware of the limitations of  PSDD-based RTCore threads, for example, no block based Unix system calls.
 
3. Memory Management/Protection

–Neutrino provides process-based memory management protection.

–RTCore, if without PSDD support, does not provide any memory management/protection. Please note that RTCore, from its nature, actually is not designed to provide any memory protection. The reason is that RTCore is not an RTOS or a Micro-Kernel. It is a patch for BSD and Linux scheduler and interrupts handler to achieve better scheduling performance. RTCore itself is not able to sustain to support any applications/threads, but must rely on BSD/Linux memory management/protection.

–RTCore, with PSDD support, is able to support having an RTCore threads running in user level privileged mode and moreover under a BSD/Linux process context. This does provide good memory protection for RTCore threads, even though not naturally.

–RTCore, with PSDD support, does provide memory protection while still without any memory management. The reason is: RTCore threads could not be viewed by BSD/Linux side schedulert. Or we say, RTCore threads should not call any block mode Unix system call interfaces including memory management part, for instance, malloc/brk. Any page fault will bring RTCore threads halt. This strict requirement makes RTCore PSDD threads programming sort of tricky. For instance, Any PSDD RTCore threads/applications will HAVE TO pre-allocate  all physical memory in advance, not able to take advantage of the Linux/BSD Paging based memory management. This behavior of RTCore, under some cases, may introduce system resources/memory allocation unfair or system starving.

4. Portability and Legacy Support

–Neutrino POSIX based codes have good portability.

– QNX, the operating system built on top of Neutrino is lack of third party application/codes support, compared to Linux/BSD even though QNX claims that most of BSD and Linux codes are able to be ported on top of it very easily. One of the big reasons is: QNX is not open source based. This is a hurt to the adoption of Neutrino micro-kernel compared to the L4 and Mach micro-kernels.
 
–RTCore based applications provide normal portability.

–RTCore applications have some good advantages over QNX/Neutrino even though QNX claims that its full POSIX based. BSD and Linux communities have huge of third party applications, while QNX side is lack of open source community support.

5. Summary
 This section is left blank intentionally

【弯曲评论相关文章：】

微内核操作系统及L4概述
QNX . Neutrino . 微内核 . 视频教程
RTLinux/RTCore局限性
RTLinux/RTCore体系结构

分享