Xenomai - Implementing aRTOS emulation
framework on GNU/Linux
xenomai-GNU/Linux上的RTOS摹擬架構(gòu)實(shí)現(xiàn)
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/
把傳統(tǒng)的RTOS移植到GNU/Linux，使linux成為1個(gè)實(shí)時(shí)嵌入式系統(tǒng)，是被廣泛接受的。它提供了類傳統(tǒng)的RTOS接口，本身這就是自由軟件組織推重的精神所在，這消除各個(gè)分類的傳統(tǒng)RTOS和LINUX世界之間的隔閡，為了那些在傳統(tǒng)RTOS世界里工作的利用設(shè)計(jì)者提供了1種平滑過渡的方式。
There is a lack of common softwareframework for developing these emulators, whereas the behavioural similaritiesbetween the traditional RTOS are obvious.
在開發(fā)這些摹擬接口的是缺少1個(gè)通用的軟件架構(gòu)，然后傳統(tǒng)的RTOS之間的行動(dòng)的相似性是明顯的存在的。（譯者注：行動(dòng)相似性，即讀、寫、調(diào)度上的實(shí)現(xiàn)原理差不多，不過是代碼差異而已）
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致性的架構(gòu)中間層和1般性的摹擬接口層，有效利用了這類相似性。建立在中間層之上的，固然也需要提供1種延續(xù)增長(zhǎng)的傳統(tǒng)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依賴于發(fā)現(xiàn)不同RTOS之間的共性，特別從線程調(diào)度和同步方面。通過利用這類相似性構(gòu)建出1個(gè)微內(nèi)核輸出1系列的1般服務(wù)接口。在更高水平的接口可以利用這些服務(wù)，反過來即實(shí)現(xiàn)了實(shí)時(shí)的利用的編程接口的摹擬實(shí)現(xiàn)，即最小化相應(yīng)的實(shí)時(shí)內(nèi)核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當(dāng)作1個(gè)嵌入式實(shí)時(shí)系統(tǒng)不是天方夜譚。讀者可以參考JerryEpplin的97年10月份發(fā)表的關(guān)于GNU/Linux在嵌入式領(lǐng)域的嵌入式系統(tǒng)編程的討論。
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到其他架構(gòu)代碼中最感興趣的部份，必定是保持初始化的設(shè)計(jì)和硬實(shí)時(shí)利用的實(shí)現(xiàn)。可靠性和運(yùn)行性能需要經(jīng)歷1個(gè)長(zhǎng)時(shí)間、復(fù)雜和消耗的工程設(shè)計(jì)進(jìn)程才能得出結(jié)果，固然這部份可能不想去讓步。因此，最好的情形，在源與目的的RTOS變成接口間建立最可能的同等性，盡可能把語法和語義斟酌在內(nèi)。
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.
這部份的解釋，可參考互斥服務(wù)中的優(yōu)先級(jí)繼承的實(shí)現(xiàn)支持。服務(wù)允許當(dāng)前線程保護(hù)自己的臨界代碼部份不受其他部份的干擾。固然這個(gè)討論的重點(diǎn)不是說是不是依賴于優(yōu)先級(jí)繼承來解決優(yōu)先級(jí)反轉(zhuǎn)，而是1個(gè)在實(shí)時(shí)利用系統(tǒng)的1個(gè)主流的設(shè)計(jì)和必須的安全保護(hù)。但僅僅強(qiáng)調(diào)的任意情況下，如果這類特性被用在源RTOS，而沒有在目標(biāo)OS中存在，那末源OS的管理策略必須根據(jù)利用被重新評(píng)估，雖然優(yōu)先級(jí)的反轉(zhuǎn)的危險(xiǎn)依然存在。
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段時(shí)間，主流的RTOS，比如VRTX,VxWorks，pSOS+等，已實(shí)現(xiàn)了實(shí)時(shí)內(nèi)核的行動(dòng)標(biāo)準(zhǔn)，主要體現(xiàn)在線程調(diào)度，內(nèi)部線程同步，和事件的異步管理。為了說明這個(gè)問題，我們可以先就中斷服務(wù)管理中斷管理中的耽憂來具體說明。
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個(gè)廣為人知的RTOS使用的方法即，鎖住重新調(diào)度進(jìn)程，直至ISR履行退出（第1個(gè)被嵌套的中斷）。以后才允許進(jìn)行再調(diào)度進(jìn)程。這類方法，即ISR運(yùn)行時(shí)，總是假定沒有同步線程被激活運(yùn)行，直至ISR退出。更多的是，由于斟酌到嵌套中斷的ISR運(yùn)行的1次性和組合性，其動(dòng)作帶來的改變，會(huì)影響側(cè)重新調(diào)度線程的順序，
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個(gè)懸掛的線程被ISR恢復(fù)，然后又被該ISR的另外1部份代碼強(qiáng)迫suspend，終究的輸出可能就是這個(gè)線程不是可運(yùn)行的，同時(shí)會(huì)保持suspend直至該ISR退出。換句話說，如果RTOS，把ISR看作1段具體的可以被線程搶占的代碼，相應(yīng)的線程可能就會(huì)在被恢復(fù)時(shí)，立即去履行，直至被重新suspend。明顯，相應(yīng)的結(jié)果可能其實(shí)不是相同的。
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個(gè)實(shí)時(shí)操作系統(tǒng)，可以通過1個(gè)協(xié)內(nèi)核的方法實(shí)現(xiàn)，它可以接收硬件中斷的管理，同時(shí)允許實(shí)時(shí)任務(wù)允許在宿主GNU/LINUX系統(tǒng)中。傳統(tǒng)的linuxkernel被看作1個(gè)低優(yōu)先級(jí)任務(wù)，作為1個(gè)實(shí)時(shí)內(nèi)核的后臺(tái)任務(wù)履行。RTlinux就是此種技術(shù)的代表。但是，這類方法有1個(gè)主要的問題，就是移植1個(gè)復(fù)雜的利用。雖然實(shí)時(shí)任務(wù)允許在linuxkernel以外，不受linuxkernel的控制，但是其實(shí)不影響GNU/Linux在移植利用時(shí)的編程模型的的實(shí)現(xiàn)。結(jié)果就是，調(diào)試和設(shè)計(jì)移植代碼的復(fù)雜度增加了。
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個(gè)傳統(tǒng)RTOS運(yùn)行1個(gè)嵌入式的利用，被簡(jiǎn)單的口述為，被目標(biāo)硬件的內(nèi)存束縛，而不是被利用本身的實(shí)時(shí)性束縛。雖然，嵌入式裝備的趨勢(shì)是更大的內(nèi)存和更高的功率，重新評(píng)估實(shí)時(shí)性是非常明智的，以保證移植到GNU/Linux到目標(biāo)平臺(tái)的影響降到最低。依照這類方式，選擇最優(yōu)的軟件架構(gòu)。1方面，接下來的情形也需要被斟酌：
? Determinism and criticality.
What is theworst case interrupt and dispatch latencies needed ?
最壞情形下的中斷履行延遲？
Does a misseddeadline lead to a catastrophic failure ?
中斷的丟失是不是會(huì)致使災(zāi)害性的后果？
? 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個(gè)低級(jí)的硬件控制？
Is the real-timeactivity coupled to non real-time services, such as GUI or databases, requiringsophisticated communications with the non real-time world ?
實(shí)時(shí)的代碼耦合到非實(shí)時(shí)的服務(wù)中，比如GUI或數(shù)據(jù)庫(kù)，是不是要求復(fù)雜的通訊？
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的實(shí)時(shí)性。嚴(yán)格的說，RTAI其實(shí)不是1個(gè)實(shí)時(shí)性O(shè)S，僅僅是作為linuxkernel的實(shí)時(shí)性擴(kuò)大，允許以任務(wù)的狀態(tài)與LinuxKernel運(yùn)行到達(dá)實(shí)時(shí)性的目的。RTAI協(xié)內(nèi)核同享硬件中斷和利用adeos虛擬層觸發(fā)的毛病和圈套事件，反過來講這樣能保證RTAI最低的中斷延遲。原始的RTAIapi提供給利用大量的有效的服務(wù)，包括計(jì)數(shù)信號(hào)量，POSIX1003.1⑴996的兼容性，比如支持pthread，mutex和條件變量，一樣增加了遠(yuǎn)程調(diào)用兼容性，郵箱，和精確的timer。大多數(shù)的服務(wù)都是可以從內(nèi)核模塊和用戶空間取得。
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種用戶空間內(nèi)上下文的硬實(shí)時(shí)任務(wù)機(jī)制，但是依然是脫離linux內(nèi)核的控制，最貼切的描寫為’用戶空間內(nèi)內(nèi)核模塊’。這類特點(diǎn)，美其名曰：LXRT，是在進(jìn)行從傳統(tǒng)RTOS移植進(jìn)程中的主要步驟，且實(shí)時(shí)任務(wù)的代碼編程毛病其實(shí)不影響linux系統(tǒng)的完全性，但需要消耗1部份微秒級(jí)的延遲時(shí)間。
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 服務(wù)仿真。第1種方法由每個(gè)實(shí)時(shí)裝備根據(jù)利用所需的，同時(shí)利用RTAI服務(wù)來實(shí)現(xiàn)仿真。Adhoc封裝接口必須支持所需的函數(shù)調(diào)用。封裝的好處在于，在1個(gè)有限的范圍內(nèi)進(jìn)行原始代碼的修改。但是，1些RTAI的行動(dòng)可能其實(shí)不是與源操作系統(tǒng)匹配。基于許多緣由，存在許多方式在仿真與原始RTAI服務(wù)的之間的沖突可能會(huì)產(chǎn)生。
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所替換。這類方案會(huì)帶來1致性的增加，由于在傳統(tǒng)的RTOS和原始RTAI接口上的基本的差異性存在，將會(huì)以損失更高的利用代碼的重寫為代價(jià)。
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小部份的傳統(tǒng)的RTOS摹擬器。他們被設(shè)計(jì)在運(yùn)行在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.
曾，這個(gè)領(lǐng)域里最突出的1個(gè)項(xiàng)目Legacy2linux。這個(gè)項(xiàng)目，由MontavistaSoftware援助，旨在提供類xenomai。通過這個(gè)項(xiàng)目可以取得兩個(gè)仿真器，1個(gè)是模仿了WindRiver的 pSOS+,另外1個(gè)是仿的VxWorks實(shí)時(shí)操作系統(tǒng)。但是，由于保護(hù)性和援助方面的缺少這個(gè)項(xiàng)目已落伍了。
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.
這個(gè)方法的有事在于開發(fā)了GNU/LINUX的用戶空間的進(jìn)程上下文，而不是在1個(gè)“hostfile”的內(nèi)核超級(jí)模式的上下文。這類方式，借助已存在的豐富的工具，比如調(diào)試器、代碼配置器和監(jiān)視器，利用開發(fā)者可以輕易的獲得。更多的，標(biāo)準(zhǔn)的linux編程模式是保存的，允許利用利用完全的用戶空間的工具（完全的POSIX支持，包括進(jìn)程內(nèi)通訊）。固然最后的不代表是最不重要的，產(chǎn)生在上下文的編程毛病，不會(huì)影響整體的系統(tǒng)的穩(wěn)定性，不像產(chǎn)生在硬實(shí)時(shí)RTAI系統(tǒng)任務(wù)中的毛病，會(huì)致使運(yùn)行中的linuxkernel產(chǎn)生嚴(yán)重的破壞。
However, we can see at least three problemsin using these emulators, depending on the application constraints:
依賴?yán)茫覀冏钌倏梢钥吹?個(gè)問題：
? 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的準(zhǔn)確的具體表示其實(shí)不會(huì)在所有調(diào)用途重現(xiàn)。換句話說，語義的兼容性是不能被保證的。（譯者注：太監(jiān)在某些情境下的功能是不完全的）
? 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，那些摹擬的實(shí)現(xiàn)，在實(shí)現(xiàn)基本的實(shí)時(shí)行動(dòng)，不會(huì)同享任何相同的基礎(chǔ)代碼，即使如此pSOS+和VxWorks之間還是同享了大部份代碼。這類情形的結(jié)果就是大媽冗余問題，在代碼的互助性來講看不到任何好處。
? 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.
? 最后，結(jié)合最新的linux2.6內(nèi)核的搶占和低延遲影響，這些摹擬器在實(shí)時(shí)性能上沒有起到?jīng)Q定性的作用。
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:
為了仿真?zhèn)鹘y(tǒng)的RTOS建立通用的架構(gòu)，我們選擇集中在所看到的通用的具體行動(dòng)。具體RTOS的特點(diǎn)是有限的，其實(shí)不會(huì)1那末1般通用，但是相對(duì)模仿來講會(huì)更有效的實(shí)現(xiàn)到微內(nèi)核中去，因此會(huì)被保存。基本行動(dòng)的選擇覆蓋了4個(gè)不同的領(lǐng)域。
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種基礎(chǔ)機(jī)制。微內(nèi)核提供了基本的多線程環(huán)境
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:
線程狀態(tài)。微內(nèi)核必須保持系統(tǒng)的每一個(gè)線程確當(dāng)前狀態(tài)。RTOS仿真器調(diào)用具體的微內(nèi)核服務(wù)，會(huì)致使?fàn)顟B(tài)從這個(gè)狀態(tài)到另外1個(gè)狀態(tài)的轉(zhuǎn)化。基本的線程狀態(tài)定義以下：
? 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狀態(tài)是累計(jì)的，意味著新創(chuàng)建的線程在從DORMANT恢復(fù)后依然保存在1個(gè)suspended的狀態(tài)。
? 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個(gè)線程在懸停1個(gè)同步資源時(shí)，可以被另外1個(gè)線程強(qiáng)迫suspend，或另外1個(gè)服務(wù)程序suspend。在在這類情況下，資源被取得后，依然保存suspend狀態(tài)，直到適合的微內(nèi)核服務(wù)將其喚醒。
? 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狀態(tài)組合起來，多是表達(dá)1個(gè)對(duì)資源的時(shí)間上的等待。在這類情況下，線程會(huì)阻塞，會(huì)被1個(gè)看門狗限定到1個(gè)有限的時(shí)間內(nèi)。
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.
調(diào)度機(jī)制。默許的，線程的調(diào)度依照固定的優(yōu)先級(jí)，利用了1個(gè)搶占邏輯。在具有相同優(yōu)先級(jí)的1組線程中也是適用的，允許他們?cè)诮o定的時(shí)間片內(nèi)運(yùn)行。更多的是，每一個(gè)線程的輪轉(zhuǎn)調(diào)度是分別獨(dú)立的時(shí)間片。
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.
優(yōu)先級(jí)管理。依賴于初始化的配置，增加或下降線程的優(yōu)先級(jí)是允許的。換句話說，數(shù)字化的更高的優(yōu)先級(jí)可以代表更高調(diào)度權(quán)限或更低調(diào)度權(quán)限，依賴于選擇的配置。在傳統(tǒng)的RTOS，這類特點(diǎn)是可以激活的。例如，VxWorks，VRTX,ThreadX和ChorusO/S 用到了反轉(zhuǎn)優(yōu)先級(jí)管理機(jī)制，數(shù)值越大優(yōu)先級(jí)越低。pSOS+反而利用相反的順序，數(shù)值越大，優(yōu)先級(jí)越高。
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.
運(yùn)行中的線程。任何給定的時(shí)間，在當(dāng)前可運(yùn)行線程中，最高優(yōu)先級(jí)的線程的可運(yùn)行時(shí)間，完全有調(diào)度器決定的。
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.
搶占。當(dāng)被1個(gè)更高優(yōu)先級(jí)線程搶占，運(yùn)行中的線程被放置到ready 隊(duì)列頭，等待處理器資源，它也沒有被suspended或阻塞。因此在沒有任何更高優(yōu)先級(jí)要求運(yùn)行之前，它期望重新獲得處理器資源。
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.
人為的輪轉(zhuǎn)。類似嘗試恢復(fù)1個(gè)準(zhǔn)備好的可運(yùn)行的線程或正在運(yùn)行的線程本身的副作用，這個(gè)線程被移動(dòng)都優(yōu)先級(jí)組的ready隊(duì)列的末尾。這個(gè)操作同等于手動(dòng)的進(jìn)行循環(huán)調(diào)度。
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:
即使沒有和上面列出的傳統(tǒng)RTOS那樣傳播廣泛，為了1些仿真器在實(shí)現(xiàn)效力的斟酌，接下來的特點(diǎn)也是被保存的。
Priorityinversion. In order to provide support forpreventing priority inversion when using inter-thread synchronization services,the priority inheritance protocol is supported.
優(yōu)先級(jí)反轉(zhuǎn)。當(dāng)利用內(nèi)部線程的同步服務(wù)，為了支持禁止優(yōu)先級(jí)反轉(zhuǎn)，優(yōu)先級(jí)繼承的協(xié)議是支持的。
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.
信號(hào)。對(duì)進(jìn)程來講，發(fā)送信號(hào)和運(yùn)行異步的服務(wù)例程是可取得的。異步服務(wù)例程的運(yùn)行，代表了信號(hào)線程的上下文切換，1旦1個(gè)或多個(gè)信號(hào)處于pending，下1次它從內(nèi)核級(jí)的履行進(jìn)程返回。
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個(gè)線程能夠以分離的方式等待多重資源。當(dāng)最少1個(gè)pending的資源可獲得時(shí)，微內(nèi)核將線程設(shè)置為非阻塞。
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.
傳統(tǒng)的RTOS提供了許多線程間的同步方式，包括信號(hào)量、消息隊(duì)列、標(biāo)志或郵箱。仔細(xì)視察，我們可以定義1個(gè)基本的可用的建立這些裝備的機(jī)制。
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些方法要末通過優(yōu)先級(jí)要末通過FIFO序列。多線程可以同時(shí)pend同1個(gè)資源。
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.
優(yōu)先級(jí)繼承。為了禁止優(yōu)先級(jí)反轉(zhuǎn)的問題，線程同步裝備結(jié)合線程調(diào)度器，實(shí)現(xiàn)了1個(gè)優(yōu)先級(jí)繼承的協(xié)議。實(shí)現(xiàn)機(jī)制允許支持優(yōu)先級(jí)的上限協(xié)議，作為1個(gè)優(yōu)先級(jí)繼承的衍生品。
Time-boundedwait. The thread synchronization facility providesa means to limit the time a thread waits for a given resource using a watchdog.
時(shí)間等待有限性。線程同步裝備提供了1種方法限制線程的等待時(shí)間，利用本身的watchdog，為了所謂的資源進(jìn)行等待。
Forcibledeletion. It is legal to destroy a resource whilethreads are pending on it. This action resumes all waiters atomically.
強(qiáng)迫刪除。當(dāng)線程在pend資源的時(shí)候燒毀資源是合法的，這個(gè)動(dòng)作自動(dòng)會(huì)喚醒所有的等待者。
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.
由于中斷的處理進(jìn)程，在RTOS設(shè)計(jì)中是最不好定義的進(jìn)程之1，微內(nèi)核集中提供1種簡(jiǎn)單的機(jī)制，依照摹擬的RTOS特點(diǎn)，建立具體的實(shí)現(xiàn)高效的回調(diào)機(jī)制。
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).
原子性：中斷就是中斷服務(wù)子程序，被稱作ISR。為了服務(wù)子程序不被線程搶占，重調(diào)度的進(jìn)程在ISR退出之前1直保持被鎖狀態(tài)。
Priority. ISRs are always considered as priority over thread execution.Interrupt prioritization is left to the underlying hardware.
優(yōu)先級(jí)：ISR的優(yōu)先級(jí)總是認(rèn)為比線程優(yōu)先級(jí)高。中斷的優(yōu)先級(jí)低于頂層硬件。
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個(gè)pod抽象鏈接到微內(nèi)核。Pod代表了關(guān)鍵的保護(hù)工作，和線程的實(shí)時(shí)調(diào)度。
The nucleus provides thread object (xnthread) and pod (xnpod)abstractions which exhibit the following characteristics:
微內(nèi)核提供了線程對(duì)象（xnthread）和pod抽象（xnpod）的具體表示，具有以下特點(diǎn)：
? 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個(gè)32bit的整形優(yōu)先級(jí)值，利用搶占邏輯來實(shí)現(xiàn)再調(diào)度。優(yōu)先級(jí)可以增加也能夠下降，具體依賴于pod的配置。
? A thread can be either waiting for initialization, forciblysuspended, pending on a resource, delayed for a count of ticks, ready-to-run orrunning.
? 線程要末是等待初始化，要末是被強(qiáng)迫suspended，要末是等待資源進(jìn)入pending，要末是等待1系列的時(shí)鐘tick，要末是等待運(yùn)行或運(yùn)行中。
? Timed wait for a resource can be bounded by a per-thread watchdog.
? 資源的時(shí)間等待可以被每一個(gè)線程的看門狗的所限定。
? The priority inheritance protocol is supported to prevent threadpriority inversion when it is detected by a synchronization object.
? 優(yōu)先級(jí)的繼承協(xié)議支持，當(dāng)1個(gè)同步目標(biāo)檢測(cè)到時(shí)，將禁止優(yōu)先級(jí)的反轉(zhuǎn)。
? A group of threads having the same base priority can undergo around-robin scheduling, each of them being given an individual time quantum.
? 具有相同優(yōu)先級(jí)的1組線程可以進(jìn)行循環(huán)調(diào)度，每一個(gè)個(gè)體都給定1個(gè)單獨(dú)的時(shí)間片。
? A support for sending signals to threads and running asynchronousservice routines (ASR) to process them is built-in.
? 內(nèi)建的信號(hào)發(fā)送機(jī)制，和異步服務(wù)支持機(jī)制
? FPU support can be optionally enabled or disabled for any thread atcreation time.
? 線程創(chuàng)建時(shí)，選擇性的支持FPU.
? Each thread can enter a disjunctive wait on multiple resources.
? 等待多重資源時(shí)，每一個(gè)線程都可進(jìn)入1個(gè)獨(dú)立的等待不干擾。
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.
微內(nèi)核提供了1個(gè)同步對(duì)象抽象（xnsynch）,旨在RTOS資源上具有1般的行動(dòng)，具有以下特點(diǎn)：
? 支持優(yōu)先級(jí)繼承，避免優(yōu)先級(jí)反轉(zhuǎn)。實(shí)現(xiàn)和調(diào)度器代碼同享。
? 支持限定時(shí)間的等待和強(qiáng)迫刪除戶的等待喚醒。
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.
微內(nèi)核需要1個(gè)時(shí)鐘源，為上層接口提供時(shí)鐘相干服務(wù)接口。配置硬件的時(shí)間片，讓利用依照給定的頻率調(diào)用用戶定義的服務(wù)。架構(gòu)上提供了1個(gè)oneshot的可編程的時(shí)鐘源，系統(tǒng)時(shí)間片可以依照不定期或定期模式運(yùn)行。不定期周期模式依然運(yùn)行定時(shí)周期的微內(nèi)核時(shí)間片。經(jīng)過每一個(gè)tick以后，由時(shí)間片管理器通過1個(gè)適合的內(nèi)部值對(duì)硬件進(jìn)行重新編程。
每個(gè)的時(shí)鐘tick都被通知到時(shí)間片管理器，即流逝時(shí)間的處理者。調(diào)度器本身利用每一個(gè)線程自己的watchdog，由于1個(gè)資源的獲得或其他緣由等待，在經(jīng)過1個(gè)有限的時(shí)間等待后，來喚醒線程。
提供1個(gè)最壞情況的有限的時(shí)間，進(jìn)行啟動(dòng)、停止或保持，需要進(jìn)行特別的關(guān)注。基于時(shí)間片輪轉(zhuǎn)的算法的時(shí)間片實(shí)現(xiàn)1鍵在NETBSD系統(tǒng)上實(shí)現(xiàn)。
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般目的性的內(nèi)存分配的建議，Xenomai內(nèi)核提供了1種動(dòng)態(tài)的內(nèi)存分配保證了實(shí)時(shí)性的要求。任何的數(shù)量的內(nèi)存堆都可以有xenomai動(dòng)態(tài)保持，唯1的限制在于系統(tǒng)的內(nèi)存的數(shù)量。
程序員人生，我編程，我富裕，記住wfuyu網(wǎng)，php教程，php學(xué)習(xí)，php手冊(cè)，CMS模版制作
聲明：本站大部分內(nèi)容是作者原創(chuàng)，少部分收集于互聯(lián)網(wǎng)供大家一起學(xué)習(xí)，原版權(quán)很多不明，如有侵權(quán)請(qǐng)聯(lián)系本站，謝謝！
粵ICP備14040726號(hào)-1?? 2015-2020 程序員人生 版權(quán)所有
