How does Xenomai 3 deliver real-time?

• By supplementing Linux with a real-time core running side-by-side with it. This small extension named Cobalt is built into the Linux kernel, dealing with all time-critical activities, such as handling interrupts, and scheduling real-time threads. The Cobalt core has higher priority over the native kernel activities.

• 通过在 Linux 旁边运行一个实时核心来增强 Linux。这个名为 Cobalt 的小型扩展被构建到Linux内核中，处理所有时间关键的活动，如处理中断和调度实时线程。Cobalt核心具有比原生内核活动更高的优先级。
In this dual kernel configuration, all the RTOS APIs Xenomai 3 provides interface with the Cobalt core, and only those APIs are deemed real-time capable, including the subset of POSIX 1003.1c services implemented by Xenomai 3 (aka libcobalt).
在这种双内核 配置中，Xenomai 3提供的所有RTOS API都与 Cobalt 核心进行接口，只有这些API被认为具有实时能力，包括Xenomai 3实现的POSIX 1003.1c服务子集（又称libcobalt）。

• By relying on the real-time capabilities of the native Linux kernel, forming the Mercury core. Often, applications will require the PREEMPT-RT extension to be enabled in the target kernel, for delivering real-time services.

• 通过依赖原生Linux内核的实时能力，形成Mercury核心。通常，应用程序需要在目标内核中启用PREEMPT-RT扩展，以提供实时服务。
However, this is not mandatory, it depends on the application requirements with respect to responsiveness and maximum jitter; some may even tolerate a certain percentage of deadline misses.
然而，这并非强制要求，这取决于应用程序对响应性和最大抖动的要求；有些应用程序甚至可以容忍一定比例的截止期限错过。
In this single kernel configuration, all the non-POSIX RTOS APIs Xenomai 3 provides are accurately emulated over the native threading library (preferably NPTL, but also supports linuxthreads for legacy setups).
在这种单内核 配置中，Xenomai 3 提供的所有非 POSIX RTOS API 都通过原生线程库（优先使用NPTL，但也支持用于传统设置的 linuxthreads）进行精确模拟。

Supported hardware

Xenomai 3 license terms

Preparation checklist

Single or dual kernel configuration?

• Does your application actually have real-time requirements, and how stringent are they? If migrating an application from an embedded RTOS to a Linux-based platform, the question may stand because unlike legacy RTOSes, Linux sees embedded and real-time characteristics as orthogonal issues. Some migrated applications may even be fine with only emulating the original RTOS API over a regular kernel and standard preemption (CONFIG_PREEMPT). Those may benefit from Xenomai 3 in single kernel configuration.

• 您的应用程序是否真的有实时性要求，这些要求有多严格？如果要将应用程序从嵌入式 RTOS迁移到基于Linux的平台，这个问题就很重要，因为与传统RTOS不同，Linux将嵌入式和实时性特征视为正交问题。某些迁移的应用程序甚至可以仅通过在常规内核和标准抢占（CONFIG_PREEMPT）上模拟原始RTOS API来满足需求。这些应用程序可能适合使用Xenomai 3的单内核配置。
• For stringent real-time requirements, you should consider the availability of the hard real-time support for your target SoC architecture and Linux kernel version.
对于严格的实时性要求，您应该考虑目标SoC架构和Linux内核版本是否支持硬实时。
• Hardware support for Xenomai 3 in dual kernel configuration can be viewed here. This approach is based on a kernel software layer which introduces a mechanism for diverting all critical events to a dual kernel extension core, coupled to the host Linux kernel. This mechanism called Dovetail implements an Interrupt pipeline.
双内核配置下Xenomai 3的硬件支持可以在这里查看。这种方法基于一个内核软件层，该层引入了一种机制，将所有关键事件转移到与主机Linux内核耦合的双内核扩展核心。这种称为Dovetail的机制实现了一个中断流水线。
• For a single kernel configuration, the list of target architectures supporting the full preemption features (aka PREEMPT-RT) is available here.
对于单内核配置，支持完全抢占特性（即PREEMPT-RT）的目标架构列表可在这里找到。
• How many CPU cores will be involved in real-time operations?
有多少CPU核心将参与实时操作？
• in a dual kernel configuration, the Xenomai 3 Cobalt core normally benefits from its simpler locking scheme when dealing with real-time activities concurrently on not more than four CPU cores.
在双内核配置中，当同时在不超过四个CPU核心上处理实时活动时，Xenomai 3 Cobalt核心通常会受益于其更简单的锁定方案。
• Beyond four CPU cores running real-time activities, SMP scalability will be better with a single kernel configuration.
对于超过四个CPU核心运行实时活动的情况，单内核配置的SMP可扩展性会更好。

• Is any of those dual kernel pros critical to your case?
• porting the Cobalt core to a new architecture is fairly simple.
• it is decoupled from the development cycle of the mainline Linux kernel, thus allowing to pick the desired (or required) kernel version more freely.
• it can simplify the worst-case analysis and keeps the results valid over update cycles of the mainline Linux kernel which hosts it.
• it allows to fine-tune the non-real-time part for throughput without negative impact on the real-time job.
• it does not require any tuning of the regular Linux system to guarantee short and bounded latencies for the real-time job.

• 以下这些双内核的优势对您的情况是否至关重要？
• 将Cobalt核心移植到新架构相对简单。
• 它与主线Linux内核的开发周期是解耦的，因此可以更自由地选择所需（或要求的）内核版本。
• 它可以简化最坏情况分析，并使结果在托管它的主线Linux内核更新周期中保持有效。
• 它允许对非实时部分进行吞吐量优化，而不会对实时任务产生负面影响。
• 它不需要对常规Linux系统进行任何调优就能保证实时任务的短暂且有界的延迟。

• Is any of those single kernel pros critical to your case?
• the stock kernel drivers can be reused by real-time applications with no change (provided they don't create latency issues due to an unfortunate implementation). On the other hand, drivers need to be specifically implemented for running over a dual kernel configuration, i.e. over the in-kernel RTDM interface.
• the programming model may be simpler than with a dual kernel configuration, since the kernel is deemed to enforce real-time behavior globally. This said, cautious application design and implementation must be a common rule regardless of the underlying real-time technology, as not all available services may be suited for real-time usage.
• all standard utilities for monitoring the system operations can report about the real-time activities out of the box. On the other hand, a dual kernel system has to adapt such tools specifically for this purpose.

• 实时应用程序可以直接复用现成的内核驱动程序而无需修改（前提是这些驱动程序的实现不会造成延迟问题）。另一方面，在双内核配置下运行的驱动程序需要专门实现，即通过内核中的RTDM接口实现。

• 由于内核被设计为全局强制执行实时行为，其编程模型可能比双内核配置更简单。话虽如此，无论底层采用何种实时技术，谨慎的应用程序设计和实现都必须是通用规则，因为并非所有可用服务都适合实时使用。

• 所有用于监控系统操作的标准工具都可以直接报告实时活动。另一方面，双内核系统必须专门适配这些工具以实现此目的。

Do you need non-POSIX real-time APIs?

Using GIT

• The GIT project documentation hub .

• GIT项目文档中心

• The GIT documentation wiki .

• GIT文档维基

Building Xenomai 3 from sources

Xenomai-3 development tree

• the master branch tracks the development HEAD toward the next major release. This branch is never rebased.

• the next branch tracks the latest commits pending merge into the master branch, it contains the most bleeding edge work. This branch may be rebased until it gets merged into the master branch eventually.

• stable-* branches track updates to stable releases, such as stable-3.2.x which is the maintenance branch for the v3.2 major release. Those branches are never rebased.

• master 分支跟踪指向下一个主要版本的开发HEAD。该分支永远不会被重基（rebase）。

• next 分支跟踪等待合并到master分支的最新提交，它包含最前沿的工作。在最终合并到master分支之前，该分支可能会被重基。

• stable-* 分支跟踪稳定版本的更新，例如stable-3.2.x是v3.2主要版本的维护分支。这些分支永远不会被重基。

If something goes wrong

Embedded Linux distributions & Xenomai