Xenomai - Implementing aRTOS emulation
framework on GNU/Linux
xenomai-GNU/Linux上的RTOS摹拟架构实现
PhilippeGerum
FirstEdition
Copyright© 2004
Copyright © 2002Philippe Gerum
Permission is granted to copy, distribute and/or modify thisdocument under the terms of the GNU Free Documentation License, Version 1.2 orany later version published by the Free Software Foundation; with no InvariantSections, no FrontCover Texts, and no Back-Cover Texts. A copy of the licenseis published on gnu.org: "GNU FreeDocumentation License" [http://www.gnu.org/licenses/fdl.html].
April2004
Abstract
Generally speaking, the Xenomai technology first aims at helpingapplication designers relying on traditional RTOS to move as smoothly aspossible to a GNU/ Linux-based execution environment, without having to rewritetheir application entirely.
This paper discusses the motivations for proposing this framework,the general observations concerning the traditional RTOS directing thistechnology, and some in-depth details about its implementation.
The Xenomai project has been launched in August 2001. It has mergedin 2003 with theRTAI project[http://www.gna.org/projects/rtai/]to produce an industrialgrade real-time Free Software platform for GNU/Linuxcalled RTAI/fusion, on top of Xenomai's abstract RTOS core. Eventually, theRTAI/fusion effort became independent from RTAI in 2005 as thexenomai project [http://www.gna.org/projects/xenomai/].
Linux is a registered trademark ofLinus Torvalds. Other trademarks cited in this paper are the property of theirrespective owner.
1. White paper.................................................................................................2
1.1. Introduction.......................................................................................2
1.2. Porting traditional RTOS-basedapplications to GNU/Linux ........................ 3
1.3. A common emulation framework.......................................................... 7
1.4. Nucleus description........................................................................... 10
1 . White paper
A simpler migration path from traditionalRTOS to GNU/Linux can favour a wider acceptance of the latter as a real-timeembedded platform. Providing emulators to mimic the traditional RTOS APIs isone of the initiative the free software community can take to fill the gapbetween the very fragmented traditional RTOS world and the GNU/Linux world, inorder for the application designers relying on traditional RTOS to move assmoothly as possible to the GNU/
把传统的RTOS移植到GNU/Linux，使linux成为1个实时嵌入式系统，是被广泛接受的。它提供了类传统的RTOS接口，本身这就是自由软件组织推重的精神所在，这消除各个分类的传统RTOS和LINUX世界之间的隔阂，为了那些在传统RTOS世界里工作的利用设计者提供了1种平滑过渡的方式。
There is a lack of common softwareframework for developing these emulators, whereas the behavioural similaritiesbetween the traditional RTOS are obvious.
在开发这些摹拟接口的是缺少1个通用的软件架构，然后传统的RTOS之间的行动的相似性是明显的存在的。（译者注：行动相似性，即读、写、调度上的实现原理差不多，不过是代码差异而已）
The Xenomai technology aims at fulfillingthis gap, by providing a consistent architecture neutral and generic emulationlayer taking advantage of these similarities. It is also committed to providean increasing set of traditional RTOS emulators built on top of this layer.
Xenomai志在消除这类隔阂，通过提供1致性的架构中间层和1般性的摹拟接口层，有效利用了这类相似性。建立在中间层之上的，固然也需要提供1种延续增长的传统RTOS仿真者的接口集合。
Xenomai relies on the common features andbehaviours found between many embedded traditional RTOS, especially from thethread scheduling and synchronization standpoints. These similarities areexploited to implement a nucleus exporting a set of generic services. Theseservices grouped in a high-level interface can be used in turn to implementemulation modules of real-time application programming interfaces, which mimicthe corresponding real-time kernel APIs.
Xenomai依赖于发现不同RTOS之间的共性，特别从线程调度和同步方面。通过利用这类相似性构建出1个微内核输出1系列的1般服务接口。在更高水平的接口可以利用这些服务，反过来即实现了实时的利用的编程接口的摹拟实现，即最小化相应的实时内核API。
A similar approach was used for the CarbonKernel [http://savannah.gnu.org/projects/carbonkernel/] project [1]in the simulation field, in which RTOS simulation models are built on top of ageneric virtual RTOS based on event-driven techniques.
The idea of using GNU/Linux as an embeddedsystem with real-time capabilities is not novel. The reader can refer to JerryEpplin's article in the October 97 issue of Embedded Systems Programming for adiscussion about GNU/Linux potential in the embedded field [2].
把GNU/Linux当作1个嵌入式实时系统不是天方夜谭。读者可以参考JerryEpplin的97年10月份发表的关于GNU/Linux在嵌入式领域的嵌入式系统编程的讨论。
Throughout this document, we will use theexpression source RTOS to indicatethe traditional real-time operating from which the application is to be ported,andtarget OS to indicate GNU/Linuxor any other free operating system to which the application could be ported.
Keeping the initial design andimplementation of a hard real-time application when attempting to port it toanother architecture is obviously of the greatest interest.Reliability andperformance may have been obtained after a long, complex and costly engineeringprocess，one does not want to compromise. Consequently, the best situation is to have the closest possibleequivalence between the source and destination RTOS programming interfaces, asfar as both the syntax and the semantics are concerned.
移植RTOS到其他架构代码中最感兴趣的部份，必定是保持初始化的设计和硬实时利用的实现。可靠性和运行性能需要经历1个长时间、复杂和消耗的工程设计进程才能得出结果，固然这部份可能不想去让步。因此，最好的情形，在源与目的的RTOS变成接口间建立最可能的同等性，尽可能把语法和语义斟酌在内。
An illustration of this can be taken fromthe support of a priority inheritance protocol [3] by the mutual exclusion services. Theseservices allow concurrent threads to protect themselves from race conditionsthat could occur into critical sections of code. The purpose of this discussionis not to argue whether relying on priority inheritance for resolving priorityinversion problems is a major design flaw or a necessary safety belt for areal-time application, but only to emphasize that any cases, if this feature isused in the source RTOS, but not available from the target OS, the resourcemanagement strategy must be reevaluated for the application, since priorityinversion risks will exists.
这部份的解释，可参考互斥服务中的优先级继承的实现支持。服务允许当前线程保护自己的临界代码部份不受其他部份的干扰。固然这个讨论的重点不是说是不是依赖于优先级继承来解决优先级反转，而是1个在实时利用系统的1个主流的设计和必须的安全保护。但仅仅强调的任意情况下，如果这类特性被用在源RTOS，而没有在目标OS中存在，那末源OS的管理策略必须根据利用被重新评估，虽然优先级的反转的危险依然存在。
During the past years, major embedded RTOS,such as VRTX, VxWorks, pSOS+ and a few others, have implemented a real-timekernel behaviour which has become a defacto standard, notably for threadscheduling, inter-thread synchronization, and asynchronous event management. Toillustrate this, let us talk about a specific concern in the interrupt servicemanagement.
在过去1段时间，主流的RTOS，比如VRTX,VxWorks，pSOS+等，已实现了实时内核的行动标准，主要体现在线程调度，内部线程同步，和事件的异步管理。为了说明这个问题，我们可以先就中断服务管理中断管理中的耽忧来具体说明。
A well-known behaviour of such RTOS is tolock the rescheduling procedure until the outer interrupt service routine (orISR) - called first upon possibly nested interrupts - has exited, after which aglobal rescheduling is finally stated. This way, an interrupt service routinecan always assume that no synchronous thread activity may run until it hasexited. Moreover, all changes impacting the scheduling order of threads, due toactions taken by any number of nested ISRs (e.g. signaling a synchronizationobject on which one or more threads are pending) are considered once andconjunctively, instead of disjunctively.
1个广为人知的RTOS使用的方法即，锁住重新调度进程，直至ISR履行退出（第1个被嵌套的中断）。以后才允许进行再调度进程。这类方法，即ISR运行时，总是假定没有同步线程被激活运行，直至ISR退出。更多的是，由于斟酌到嵌套中断的ISR运行的1次性和组合性，其动作带来的改变，会影响侧重新调度线程的顺序，
For instance, if a suspended thread isfirst resumed by an ISR, then forcibly suspended later by another part of thesame ISR, the outcome will be that the thread will not run, and remainsuspended after the ISR has exited. In the other hand, if the RTOS sees ISRs asnon-specific code that can be preempted by threads, the considered thread willbe given the opportunity to execute immediately after it is resumed, until itis suspended anew. Obviously, the respective resulting situations won't beidentical.
例如，如果1个悬挂的线程被ISR恢复，然后又被该ISR的另外1部份代码强迫suspend，终究的输出可能就是这个线程不是可运行的，同时会保持suspend直至该ISR退出。换句话说，如果RTOS，把ISR看作1段具体的可以被线程抢占的代码，相应的线程可能就会在被恢复时，立即去履行，直至被重新suspend。明显，相应的结果可能其实不是相同的。
Making GNU/Linux a hard real-time system iscurrently achieved by using a co-kernel approach which takes control of thehardware interrupt management, and allows running real-time tasks seamlesslyaside of the hosting GNU/Linux system [4]. The 'regular' Linux kernel iseventually seen as a low-priority, background of the small real-time executive.TheRTLinux [http://www.rtlinux.org]project is representative of this technical path. However, this approach has amajor drawback when it comes to port complex applications from a foreignsoftware platform: since the real-time tasks run outside the Linux kernelcontrol, the GNU/Linux programming model cannot be preserved when porting theseapplications. The result is an increased complexity in redesigning anddebugging the ported code.
使GNU/LINUX成为1个实时操作系统，可以通过1个协内核的方法实现，它可以接收硬件中断的管理，同时允许实时任务允许在宿主GNU/LINUX系统中。传统的linuxkernel被看作1个低优先级任务，作为1个实时内核的后台任务履行。RTlinux就是此种技术的代表。但是，这类方法有1个主要的问题，就是移植1个复杂的利用。虽然实时任务允许在linuxkernel以外，不受linuxkernel的控制，但是其实不影响GNU/Linux在移植利用时的编程模型的的实现。结果就是，调试和设计移植代码的复杂度增加了。
In some cases, choosing a traditional RTOSto run an embedded application has been initially dictated by the memoryconstraints imposed by the target hardware, instead of actual realtimeconstraints imposed by the application itself. Since embedded devices tend toexhibit ever increasing memory and processing horsepower, it seems judicious toreevaluate the need for real-time guarantee when considering the porting effortto GNU/Linux on a new target hardware. This way, the best underlying softwarearchitecture can be selected. In this respect, the following, the followingcriteria need to be considered:
有些情况下，选择的1个传统RTOS运行1个嵌入式的利用，被简单的口述为，被目标硬件的内存束缚，而不是被利用本身的实时性束缚。虽然，嵌入式装备的趋势是更大的内存和更高的功率，重新评估实时性是非常明智的，以保证移植到GNU/Linux到目标平台的影响降到最低。依照这类方式，选择最优的软件架构。1方面，接下来的情形也需要被斟酌：
• Determinism and criticality.
What is theworst case interrupt and dispatch latencies needed ?
最坏情形下的中断履行延迟？
Does a misseddeadline lead to a catastrophic failure ?
中断的丢失是不是会致使灾害性的后果？
• Programming model
What is theoverall application complexity, provided that the higher the complexity, thegreater the need for powerful debugging aid and monitoring tools.
• Is there a need need forlow-level hardware control ?
• 是不是需要1个低级的硬件控制？
Is the real-timeactivity coupled to non real-time services, such as GUI or databases, requiringsophisticated communications with the non real-time world ?
实时的代码耦合到非实时的服务中，比如GUI或数据库，是不是要求复杂的通讯？
In order to get whether hard or softreal-time support, several GNU/Linux-based solutions exist [5][6]. It is notthe purpose of this paper to present them all exhaustively. We will onlyconsider a two fold approach based on free software solutions which is likelyto be suited for many porting taskings, depending on the actual real-timeconstraints imposed by the application.
Real-timeenabling GNU/Linux using RTAI. Strictly speakingLinux/RTAI [7] is not a real-time operating system but rather a real-time Linuxkernel extension, which allows running real-time tasks seamlessly aside of thehosting GNU/Linux system. The RTAI cokernel shares hardware interrupts andsystem-originated events like traps and faults with the Linux kernel using theAdeos [http://www.adeos.org/]virtualization layer, which in turn ensures RTAI low interrupt latencies. Thenative RTAI API provides the applications a wealth of useful services,including counting semaphores, POSIX 1003.1⑴996 facilities such as pthreads,mutexes and condition variables, also adding remote procedure call facility, mailboxes,and precision timers. Most services are symmetrically available from kernelmodule and user-space programs.
利用RTAI使能GNU/Linux的实时性。严格的说，RTAI其实不是1个实时性OS，仅仅是作为linuxkernel的实时性扩大，允许以任务的状态与LinuxKernel运行到达实时性的目的。RTAI协内核同享硬件中断和利用adeos虚拟层触发的毛病和圈套事件，反过来讲这样能保证RTAI最低的中断延迟。原始的RTAIapi提供给利用大量的有效的服务，包括计数信号量，POSIX1003.1⑴996的兼容性，比如支持pthread，mutex和条件变量，一样增加了远程调用兼容性，邮箱，和精确的timer。大多数的服务都是可以从内核模块和用户空间取得。
RTAI 2.x and 3.x provide a means to executehard real-time tasks in user-space context (x86 only), but still outside theLinux kernel control, which is best described as running 'user-space kernelmodules'. This feature, namely LXRT, is a major step toward a simpler migrationpath from traditional RTOS, since programming errors occuring within real-timetasks don't jeopardize the overall GNU/Linux system sanity, at the expense of afew microseconds more latency.
RTAI 2.X 和3.x版本提供1种用户空间内上下文的硬实时任务机制，但是依然是脱离linux内核的控制，最贴切的描写为’用户空间内内核模块’。这类特点，美其名曰：LXRT，是在进行从传统RTOS移植进程中的主要步骤，且实时任务的代码编程毛病其实不影响linux系统的完全性，但需要消耗1部份微秒级的延迟时间。
Adhoc services emulation. A first approach consistsin emulating each real-time facility needed by the application using acombination of the RTAI services. An ad hoc wrapping interface has to bewritten to support the needed function calls. The benefit of the wrappingapproach lies in the limited modifications made to the original code. However,some RTAI behaviours may not be compliant with the source operating system's.For the very same reason, conflicts between the emulated and native RTAIservices may occur in some way.
Ad hoc 服务仿真。第1种方法由每个实时装备根据利用所需的，同时利用RTAI服务来实现仿真。Adhoc封装接口必须支持所需的函数调用。封装的好处在于，在1个有限的范围内进行原始代码的修改。但是，1些RTAI的行动可能其实不是与源操作系统匹配。基于许多缘由，存在许多方式在仿真与原始RTAI服务的之间的冲突可能会产生。
Complete port to RTAI. A second approach consists in fully porting the application overthe native RTAI API. In such a case, RTAI facilities are globally substitutedfrom the facilities from the source RTOS. This solution brings improvedconsistency at the expense of a possible large-scale rewriting of theapplication, due to some fundamental behavioural differences that may existbetween the traditional RTOS and the native RTAI interface.
RTAI的代码移植。第2种方法讲述的是移植利用到原始的RTAIAPI。在这类情况下，RTAI装备是被源RTOS所替换。这类方案会带来1致性的增加，由于在传统的RTOS和原始RTAI接口上的基本的差异性存在，将会以损失更高的利用代码的重写为代价。
A few traditional RTOS emulators exists inthe free software world. There are generally designed on top of the GNU/LinuxPOSIX 1003.1⑴996 layer, and allow to emulate the source RTOS API in auser-space execution context, under the control of the Linux kernel.
在自由软件世界，存在1小部份的传统的RTOS摹拟器。他们被设计在运行在GNU/Linux的 POSIX层之上，允许用户接口的RTOS API，并且受linuxkernel的控制。
Once one of the most proeminent effort inthis area used to be the Legacy2linux project [8]. This project, sponsored byMontavista Software, aimed at providing ["a series of Linux-residentemulators for various legacy RTOS kernels."] Just like Xenomai, [ theseemulators are designed to ease the task of porting legacy RTOS code to anembedded Linux environment".] Two emulators have been made available bythis project, respectively mimicking the APIs of WindRiver's pSOS+ and VxWorksreal-time operating systems. However, this project has stalled due to a lack ofmaintenance and contribution.
曾，这个领域里最突出的1个项目Legacy2linux。这个项目，由MontavistaSoftware援助，旨在提供类xenomai。通过这个项目可以取得两个仿真器，1个是模仿了WindRiver的 pSOS+,另外1个是仿的VxWorks实时操作系统。但是，由于保护性和援助方面的缺少这个项目已落伍了。
The benefits of this approach is mainly tokeep the development process in the GNU/ Linux user-space environment, insteadof moving to a rather 'hostile' kernel/supervisor mode context. This way, therich set of existing tools such as debuggers, code profilers, and monitorsusable in this context are immediatly available to the application developer. Moreover, the standard GNU/Linux programming model is preserved,allowing the application to use the full set of of facilities existing in theuser space (e.g. full POSIX support, including inter-process communication).Last but not least, programming errors occuring in this context don'tjeopardize the overall GNU/Linux system stability, unlike what can happen if abug is encountered on behalf of a hard real-time RTAI task which could causeserious damages to the running Linux kernel.
这个方法的有事在于开发了GNU/LINUX的用户空间的进程上下文，而不是在1个“hostfile”的内核超级模式的上下文。这类方式，借助已存在的丰富的工具，比如调试器、代码配置器和监视器，利用开发者可以轻易的获得。更多的，标准的linux编程模式是保存的，允许利用利用完全的用户空间的工具（完全的POSIX支持，包括进程内通讯）。固然最后的不代表是最不重要的，产生在上下文的编程毛病，不会影响整体的系统的稳定性，不像产生在硬实时RTAI系统任务中的毛病，会致使运行中的linuxkernel产生严重的破坏。
However, we can see at least three problemsin using these emulators, depending on the application constraints:
依赖利用，我们最少可以看到3个问题：
• First, the emulated API they provide is usually incomplete for aneasy port from the source RTOS. In other words, only a limited syntacticcompatibility is available.
• 首先，被摹拟的接口常常是不完全的从源RTOS的轻量型移植。换句话说，就是只有有限的语法兼容性。
• Second, the exact behaviour of the source RTOS is not reproduced forall the functional areas. In other words, the semantic compatibility might notbe guaranteed.
• 第2，源RTOS的准确的具体表示其实不会在所有调用途重现。换句话说，语义的兼容性是不能被保证的。（译者注：太监在某些情境下的功能是不完全的）
• These emulators don't share anycommon code base for implementing the fundamental real-time behaviours, even soboth pSOS+ and VxWorks share most of them.The resulting situation leads to redundant implementation efforts, without anybenefit one can see in code mutualization.
• 第3，那些摹拟的实现，在实现基本的实时行动，不会同享任何相同的基础代码，即使如此pSOS+和VxWorks之间还是同享了大部份代码。这类情形的结果就是大妈冗余问题，在代码的互助性来讲看不到任何好处。
• And finally, even combined to the latest Linux 2.6 features likefine-grain kernel preemption and low latency efforts, these emulators cannotdeliver deterministic real-time performance.
• 最后，结合最新的linux2.6内核的抢占和低延迟影响，这些摹拟器在实时性能上没有起到决定性的作用。
In order to build a generic and versatileframework for emulating traditional RTOS, we chose to concentrate on a set ofcommon behaviours they all exhibit. A limited set of specific RTOS featureswhich are not so common, but would be more efficiently implemented into thenucleus than into the emulators, has also been retained. The basic behavioursselected cover four distinct fields:
为了仿真传统的RTOS建立通用的架构，我们选择集中在所看到的通用的具体行动。具体RTOS的特点是有限的，其实不会1那末1般通用，但是相对模仿来讲会更有效的实现到微内核中去，因此会被保存。基本行动的选择覆盖了4个不同的领域。
Multi-threading provides the fundamentalmechanism for an application to control and react to multiple, discrete externalevents. The nucleus provides the basic multi-threading environment.
多线程，为那些多重的分散的外部事件做集中控制，提供了1种基础机制。微内核提供了基本的多线程环境
Threadstates. The nucleus has to maintain the currentstate of each thread in the system. A state transition from one state toanother may occur as the result of specific nucleus services called by the RTOSemulator. The fundamental thread states defined by the nucleus are:
线程状态。微内核必须保持系统的每一个线程确当前状态。RTOS仿真器调用具体的微内核服务，会致使状态从这个状态到另外1个状态的转化。基本的线程状态定义以下：
• DORMANT and SUSPENDED states are cumulative, meaning that the newlycreated thread will still remain in a suspended state after being resumed fromthe DORMANT state.
• DORMANT 和 SUSPENDED状态是累计的，意味着新创建的线程在从DORMANT恢复后依然保存在1个suspended的状态。
• PENDING and SUSPENDED states are cumulative too, meaning that athread can be forcibly suspended by another thread or service routine whilepending on a synchronization resource (e.g. semaphore, message queue). In sucha case, the resource is dispatched to it, but it remains suspended untilexplicitly resumed by the proper nucleus service.
• PENDING 和SUSPENDED也是1样，意味着，1个线程在悬停1个同步资源时，可以被另外1个线程强迫suspend，或另外1个服务程序suspend。在在这类情况下，资源被取得后，依然保存suspend状态，直到适合的微内核服务将其唤醒。
• PENDING and DELAYED states may be combined to express a timed waiton a resource. In such a case, the time the thread can be blocked is bound to alimit enforced by a watchdog.
• PENDING 和DELAYED状态组合起来，多是表达1个对资源的时间上的等待。在这类情况下，线程会阻塞，会被1个看门狗限定到1个有限的时间内。
Schedulingpolicies. By default, threads are scheduledaccording to a fixed priority value, using a preemptive algorithm. There isalso a support for round-robin scheduling among a group of threads having thesame priority, allowing them to run during a given time slice, in rotation.Moreover, each thread undergoing the round-robin scheduling is given anindividual time quantum.
调度机制。默许的，线程的调度依照固定的优先级，利用了1个抢占逻辑。在具有相同优先级的1组线程中也是适用的，允许他们在给定的时间片内运行。更多的是，每一个线程的轮转调度是分别独立的时间片。
Prioritymanagement. It is possible to use either anincreasing or decreasing thread priority ordering, depending on an initialconfiguration. In other words, numerically higher priority values could eitherrepresent higher or lower scheduling priorities depending on the configurationchosen. This feature is motivated by the existence of this two possibleordering among traditional RTOS. For instance, VxWorks, VRTX, ThreadX and ChorusO/S use a reversed priority management scheme, where the higher the value, thelower the priority. pSOS+ instead uses the opposite ordering, in which thehigher the value, the higher the priority.
优先级管理。依赖于初始化的配置，增加或下降线程的优先级是允许的。换句话说，数字化的更高的优先级可以代表更高调度权限或更低调度权限，依赖于选择的配置。在传统的RTOS，这类特点是可以激活的。例如，VxWorks，VRTX,ThreadX和ChorusO/S 用到了反转优先级管理机制，数值越大优先级越低。pSOS+反而利用相反的顺序，数值越大，优先级越高。
Runningthread. At any given time, the highest prioritythread which has been ready to run for the longest time among the currently runnablethreads (i.e. not currently blocked by any delay or resource wait) is electedto run by the scheduler.
运行中的线程。任何给定的时间，在当前可运行线程中，最高优先级的线程的可运行时间，完全有调度器决定的。
Preemption. When preempted by a higher priority thread, the running thread isput at the front of the ready thread queue waiting for the processor resource,provided it has not been suspended or blocked in any way. Thus it is expectedto regain the processor resource as soon as no other higher priority activity(i.e. a thread having a higher priority level, or an interrupt service routine)is eligible for running.
抢占。当被1个更高优先级线程抢占，运行中的线程被放置到ready 队列头，等待处理器资源，它也没有被suspended或阻塞。因此在没有任何更高优先级要求运行之前，它期望重新获得处理器资源。
Manualround-robin. As a side-effect of attempting toresume an already runnable thread or the running thread itself, this thread ismoved at the end of its priority group in the ready thread queue. Thisoperation is functionally equivalent to a manual round-robin scheduling.
人为的轮转。类似尝试恢复1个准备好的可运行的线程或正在运行的线程本身的副作用，这个线程被移动都优先级组的ready队列的末尾。这个操作同等于手动的进行循环调度。
Even if they are not as widespread as thoseabove in traditional RTOS, the following features are also retained for thesake of efficiency in the implementation of some emulators:
即使没有和上面列出的传统RTOS那样传播广泛，为了1些仿真器在实现效力的斟酌，接下来的特点也是被保存的。
Priorityinversion. In order to provide support forpreventing priority inversion when using inter-thread synchronization services,the priority inheritance protocol is supported.
优先级反转。当利用内部线程的同步服务，为了支持禁止优先级反转，优先级继承的协议是支持的。
Signaling. A support for sending signals to threads and running asynchronousservice routines to process them is available. The asynchronous service routineis run on behalf of the signaled thread context the next time it returns fromthe nucleus level of execution, as soon as one or more signals are pending.
信号。对进程来讲，发送信号和运行异步的服务例程是可取得的。异步服务例程的运行，代表了信号线程的上下文切换，1旦1个或多个信号处于pending，下1次它从内核级的履行进程返回。
Disjunctivewait. A thread is able to wait in a disjunctivemanner on multiple resources. The nucleus unblocks the thread when at least oneof the pending resources is available.
分离等待。1个线程能够以分离的方式等待多重资源。当最少1个pending的资源可获得时，微内核将线程设置为非阻塞。
Traditional RTOS provide a large spectrumof inter-thread communication facilities involving thread synchronization, suchas semaphores, message queues, event flags or mailboxes.Lookingat them closely, we can define the characteristics of a basic mechanism whichwill be usable in turn to build these facilities.
传统的RTOS提供了许多线程间的同步方式，包括信号量、消息队列、标志或邮箱。仔细视察，我们可以定义1个基本的可用的建立这些装备的机制。
Pending mode. The thread synchronization facility provides a means for threads topend either by priority or FIFO ordering. Multiple threads should be able topend on a single resource.
Pending模式。线程同步装备提供1些方法要末通过优先级要末通过FIFO序列。多线程可以同时pend同1个资源。
Priorityinheritance protocol. In order to prevent priorityinversion problems, the thread synchronization facility implements a priorityinheritance protocol in conjunction with the thread scheduler. Theimplementation allows for supporting the priority ceiling protocol as a derivativeof the priority inheritance protocol.
优先级继承。为了禁止优先级反转的问题，线程同步装备结合线程调度器，实现了1个优先级继承的协议。实现机制允许支持优先级的上限协议，作为1个优先级继承的衍生品。
Time-boundedwait. The thread synchronization facility providesa means to limit the time a thread waits for a given resource using a watchdog.
时间等待有限性。线程同步装备提供了1种方法限制线程的等待时间，利用本身的watchdog，为了所谓的资源进行等待。
Forcibledeletion. It is legal to destroy a resource whilethreads are pending on it. This action resumes all waiters atomically.
强迫删除。当线程在pend资源的时候烧毁资源是合法的，这个动作自动会唤醒所有的等待者。
Since the handling ofinterrupts is one of the least well defined areas in RTOS design,the nucleus focuses on providing a simple mechanism with sufficienthooks for specific implementations to be built onto according to the emulatedRTOS flavour.
由于中断的处理进程，在RTOS设计中是最不好定义的进程之1，微内核集中提供1种简单的机制，依照摹拟的RTOS特点，建立具体的实现高效的回调机制。
Nesting. Interrupt management code is reentrant in order to supportinterrupt nesting safely.
嵌套：为了支持中断嵌套，中断管理代码是可重入的。
Atomicity. Interrupts are associated with dedicated service routines calledISRs. In order for these routines not to be preempted by thread execution, therescheduling procedure is locked until the outer ISR has exited (i.e. in caseof nested interrupts).
原子性：中断就是中断服务子程序，被称作ISR。为了服务子程序不被线程抢占，重调度的进程在ISR退出之前1直保持被锁状态。
Priority. ISRs are always considered as priority over thread execution.Interrupt prioritization is left to the underlying hardware.
优先级：ISR的优先级总是认为比线程优先级高。中断的优先级低于顶层硬件。
Traditional RTOS usually represent time inunits of ticks. These are clock-specific time units and are usually the periodof the hardware timer interrupt, or a multiple thereof. Since it needs tosupport both periodic and aperiodic time sources, the nucleus transparentlyswitches from periodic jiffies to time-stamp counter values depending on thecurrent timer operating mode.
Softwaretimer support. A watchdog facility is provided tomanage time-bound operations by the nucleus.
Absoluteand relative clock. The nucleus keeps a globalclock value which can be set by the RTOS emulator as being the system-definedepoch.
Some RTOS like pSOS+ also provide supportfor date-based timing, but conversion of ticks into conventional time and dateunits is an uncommon need that should be taken in charge by the RTOS emulatoritself.
After having selected the basic behaviours shared by traditionalRTOS, we have implemented them in a nucleus exporting a few service classes.These generic services will then serve as a founding layer for developing eachemulated RTOS API, according to their own flavour and semantics.
In order for this layer to be architectureneutral, the needed support for hardware control and real-time capabilitieswill be obtained from an underlying host software architecture, through arather simple standardized interface. Thus, porting the nucleus to a newrealtime architecture will solely consist in implementing this low-levelinterface for the target platform.
The host software architecture is expected to provide the primaryreal-time capabilities to the RTOS abstraction layer. Basically, the hostreal-time layer must handle at least the following tasks:
• On request start/stop dispatching the external interrupts to aspecialized handler ;
• Provide a means to mask and unmask interrupts ;
• Provide a means to create new threads of control in their simplestform ;
• Provide support for periodic and aperiodic interrupt sources used intimer management ;
• Provide support for allocating chunks of non-pageable memory.
Xenomai aims at helping applicationdesigners relying on traditional RTOS to move as smoothly as possible to aGNU/Linux-based execution environment, without having to rewrite theirapplications entirely. Aside of the advantages of using GNU/Linux as anembedded system, the benefits expected from the described approach is mainly areduced complexity in designing new RTOS emulations. The architecture-neutralabstraction layer provides the foundation for developing accurate emulations oftraditional RTOS API, saving the burden of repeatedly implementing theirfundamental real-time behaviours. Since the abstraction layer also favours codesharing and mutualization, we can expect the RTOS emulations to take advantageof them in terms of code stability and reliability.
RTOS emulations are software modules whichconnect to the nucleus through the pod abstraction. The pod is responsible forthe critical housekeeping chores, and the real-time scheduling of threads.
RTOS仿真器是软件模块，它通过1个pod抽象链接到微内核。Pod代表了关键的保护工作，和线程的实时调度。
The nucleus provides thread object (xnthread) and pod (xnpod)abstractions which exhibit the following characteristics:
微内核提供了线程对象（xnthread）和pod抽象（xnpod）的具体表示，具有以下特点：
• Threads are scheduled according to a 32bit integer priority value,using a preemptive algorithm. Priority ordering can be increasing or decreasingdepending on the pod configuration.
• 线程通过1个32bit的整形优先级值，利用抢占逻辑来实现再调度。优先级可以增加也能够下降，具体依赖于pod的配置。
• A thread can be either waiting for initialization, forciblysuspended, pending on a resource, delayed for a count of ticks, ready-to-run orrunning.
• 线程要末是等待初始化，要末是被强迫suspended，要末是等待资源进入pending，要末是等待1系列的时钟tick，要末是等待运行或运行中。
• Timed wait for a resource can be bounded by a per-thread watchdog.
• 资源的时间等待可以被每一个线程的看门狗的所限定。
• The priority inheritance protocol is supported to prevent threadpriority inversion when it is detected by a synchronization object.
• 优先级的继承协议支持，当1个同步目标检测到时，将禁止优先级的反转。
• A group of threads having the same base priority can undergo around-robin scheduling, each of them being given an individual time quantum.
• 具有相同优先级的1组线程可以进行循环调度，每一个个体都给定1个单独的时间片。
• A support for sending signals to threads and running asynchronousservice routines (ASR) to process them is built-in.
• 内建的信号发送机制，和异步服务支持机制
• FPU support can be optionally enabled or disabled for any thread atcreation time.
• 线程创建时，选择性的支持FPU.
• Each thread can enter a disjunctive wait on multiple resources.
• 等待多重资源时，每一个线程都可进入1个独立的等待不干扰。
The nucleus provides a synchronizationobject abstraction (xnsynch) aimed atimplementing the common behaviour of RTOS resources, which has the followingcharacteristics:
• Support for the priority inheritance protocol, in order to preventpriority inversion problems. The implementation is shared with the schedulercode.
• Support for time-bounded wait and forcible deletion with waitersawakening.
微内核提供了1个同步对象抽象（xnsynch）,旨在RTOS资源上具有1般的行动，具有以下特点：
• 支持优先级继承，避免优先级反转。实现和调度器代码同享。
• 支持限定时间的等待和强迫删除户的等待唤醒。
The nucleus needs a time source to providethe time-related services to the upper interfaces. The timer hardware needs tobe configured so that a user-defined routine is called according to a givenfrequency. On architectures that provide a oneshot-programmable time source,the system timer can operate either in aperiodic or periodic mode. Using theaperiodic mode still allows to run periodic nucleus timers over it: theunderlying hardware will simply be reprogrammed after each tick by the timermanager using the appropriate interval value.
Each incoming clock tick is announced tothe timer manager which fires in turn the timeout handlers of elapsed timers.The scheduler itself uses per-thread watchdogs to wake up threads undergoing abounded time wait, while waiting for a resource availability or being delayed.
A special care has been taken to offerbounded worst-case time for starting, stopping and maintaining timers. Thetimer facility is based on the timer wheel algorithm[11] described by Adam M.Costello and George Varghese, which is implemented in the NetBSD operatingsystem for instance.
微内核需要1个时钟源，为上层接口提供时钟相干服务接口。配置硬件的时间片，让利用依照给定的频率调用用户定义的服务。架构上提供了1个oneshot的可编程的时钟源，系统时间片可以依照不定期或定期模式运行。不定期周期模式依然运行定时周期的微内核时间片。经过每一个tick以后，由时间片管理器通过1个适合的内部值对硬件进行重新编程。
每个的时钟tick都被通知到时间片管理器，即流逝时间的处理者。调度器本身利用每一个线程自己的watchdog，由于1个资源的获得或其他缘由等待，在经过1个有限的时间等待后，来唤醒线程。
提供1个最坏情况的有限的时间，进行启动、停止或保持，需要进行特别的关注。基于时间片轮转的算法的时间片实现1键在NETBSD系统上实现。
Xenomai's nucleus provides dynamic memory allocation support withreal-time guarantee, based on McKusick's and Karels' proposal for a generalpurpose memory allocator[10]. Any number of memory heaps can be maintaineddynamically by Xenomai, only limited by the actual amount of system memory.
基于McKusick和Karels的1般目的性的内存分配的建议，Xenomai内核提供了1种动态的内存分配保证了实时性的要求。任何的数量的内存堆都可以有xenomai动态保持，唯1的限制在于系统的内存的数量。
程序员人生，我编程，我富裕，记住wfuyu网，php教程，php学习，php手册，CMS模版制作
声明：本站大部分内容是作者原创，少部分收集于互联网供大家一起学习，原版权很多不明，如有侵权请联系本站，谢谢！
粤ICP备14040726号-1 2015-2020 程序员人生 版权所有
