[置顶] Life With Adeos

栏目：框架设计时间：2015-06-12 07:56:50

Life With Adeos

Philippe Gerum

Revision B

在遵守由自由软件基金会发布的1.2或更高版本的GNU Free Documentation License的条件下授与许可复制，分发和/或修改本文件。无固定段落，封面文字和封底文字。许可的1个副本发布在gnu.org上：“GNU Free Documentation License”[http://www.gnu.org/licenses/fdl.html]。

10/9/2005

摘要

这篇文档是Adeos技术的概述和它为Xenomai提供的支持。介绍了解决事件管线、中断分发的实现和系统事件传播以后，我们将学习Xenomai与Adeos之间的交互影响。我们将会解释重要和次要的域的概念并且我们对中断是怎样被传播的也感兴趣。我们最后将以总结1些启用/禁用中断源和在域间同享中断的技能和诀窍的方式结束。

1. 甚么是Adeos

Adeos是作为1个Linux内核补钉的资源虚拟层，它的通用设计早在2001年由 Karim Yaghmour在1个技术文件中提议的。

这个提议确当前化身是它成为1个简单、高效的实时系统的推动者。它提供了1种方法来运行1个常规的GNU/Linux环境和1个RTOS在相同的硬件上并行履行。

为此，Adeos启用了多个实体――称作域――同时存在于同1个机器上。这些域不需要看见彼此，但是它们都能看见Adeos。1个域极可能是1个完全的操作系统，但是没有假定斟酌域中的复杂性。但是，所有的域都可能争着处理外部事件（例如中断）或内部的（例如圈套、异常），根据它们已取得的全系统的优先级。

另外，其简单的虚拟化能力，另外1个关键的Adeos的优势在于它有能力导出1个通用的API到客户域，这个不依赖于CPU的体系结构。因此，许多如果不是大部份产生在客户域的移植工作会产生在Adeos层。

1.1. 事件管线

必须牢记的是Adeos基本的结构是客户域征求事件控制链。域是1个内核软件组件可以告知Adeos层被甚么通知：

每个传入的外部中断或自动产生的虚拟中断；
每个Linux利用程序产生的系统调用；
内核代码触发的其他的系统事件（例如，Linux任务切换，信号通知，Linux任务退出等等）

Adeos确保事件根据它们在系统中各自相应的优先级有条不紊的被分发到各个客户端领域，所以为这些事件提供及时和可预测的分发是可能的。这个优先级严格定义了事件被分发到域的顺序。所有活动的域根据它们各自的优先级排队，构成了Adeos使用的管线抽象来从最高优先级到最低优先级的域构成事件流。传入事件（包括中断）配推动到管线的头部（即，最高优先级域）处理到它的尾部（即，最低优先级域）。下图给出了1个某个基于Adeos系统的通用试图，在这里多个域通过管线抽象同享事件：

事件管线示意图

在上图中，Linux内核关于管线上的位置可以是任意的；也就是说，Linux内核还有1个特殊的作用由于它代表了根域，由于所有其他的域需要Linux去安装它们，通常意味着加载内核模块。

1.2. 乐观的中断保护

为了以优先级的方式分发中断，同时仍允许域创建无中断部份，Adeos实现了Stodolsky, Chen, 和 Bershad描写的所谓的乐观的中断保护模型。在这篇的论文中。[http://citeseer.nj.nec.com/stodolsky93fast.html]

任何给定的域占用管线的阶段都能被推延，这意味着下1个到达的中断将不会被分发到域的处理者并将会被禁止以一样的举动流到最低优先级域。当1个阶段被推延，暂停的中断积累在域中断日志中，终究在这个阶段不再被推延时被1个名为同步的内部操作处理。域使用这类特点来保护他们自己的临界区不被他们自己的中断处理有害的抢占。但是，多亏Adeos带来的中断控制虚拟化，1个更高优先级的域仍能接收中断并且终究抢占任何低优先级域。实际上，这意味着，即便1个基于Adeos的Linux内核常常推延它自己的阶段来处理临界区操作，1个提早运行的实时系统在管线中仍能在任什么时候候够接收中断，不会产生任何延迟。

当1个域处理完了它所接收到的待处理的中断，它会调用1个特殊的Adeos服务让出CPU到管线的下1个域，所以后者可以顺次处理唤醒它的待处理的事件并且这个周期会延续到管线的最低优先级域。

下图说明了运行在多CPU上的多个域怎样通过Adeos管线抽象同享传入的中断。固然，当1个阶段被推延，必须正确的标记待解决中断：这是通过1个每域，每CPU中断日志实现的，见下面的解释：

乐观的中断保护模型

1.3. 系统时间传播

中断不是唯逐一种可以流经管线抽象的事件；Linux内核自己触发的内部事件或它的利用程序产生的所谓的系统事件。从根本上说，系统事件是圈套、异常或某些Linux内核的动作的同步通知，并通过管线通知任何感兴趣的部份。

由于这些事件的本质是同步的，没有办法通过推延操作推延他们的唤醒，仅仅是由于你不能延迟他们的处理。这样设计决定的根据来源于这样1个事实：代码触发1个系统事件可能仅仅是没有响应处理程序的干预不能继续处理：例如，缺页处理程序在内存寻址异常后应当立即履行，延迟它没有任何意义。换句话说，在给定的域上的延迟/非延迟操作仅仅关心中断，不论是真实的还是虚拟的。

2. Adeos为Xenomai提供了甚么？

相反的，这个问题也能够是：Xenomai需要提供的实时服务的基本保证是甚么？答案简单明了：在Linux内核有机会去通知他们之前，它必须被允许第1个处理所有的传入的中断，并且必须有能力立即处理他们不管当前进程试图从Linux内核使用CPU中断掩码锁定它们。它也必须确保始终履行适当的线程的优先级管理不管他们当前的履行域。

这些保证给Xenomai可预测性的中断过延迟在最低的微秒层次范围内，不论Linux正在经历甚么活动，1旦加上LLinux任务的Xenomai快速协同调度技术（即，影子线程），提供了实时线程肯定的调度延迟。下图说明了Adoes层在Xenomai体系结构中的位置：

Adeos在Xenomai体系结构中的位置

你将会注意到Adeos接口直接暴露在硬件抽象层构成了Xenomai核的基础。因此，大多数对Adeos服务的要求从HAL层开始解决，它的实现能在相干arch/<archname>/hal目录中找到，通用的位可以在arch/generic/hal下取得。看1看后者是最好的方法去理解Xenomai怎样为了自己的目的利用Adeos的。

2.1. Xenomai的重要和次要域

Xenomai允许运行实时线程在严格内核空间或在Linux线程地址空间。在文章剩下的部份，我们把后者称作Xenomai线程，不会与常规Linux任务产生混淆（即便他们属于 SCHED_FIFO 类）。Xenomai管理的所有线程

可以从实时nucleus中获知。

支持实时线程排他的运行在内核空间仅仅是1个共同核时期的1个回想，在用户空间真实时支持来临之前，当实时利用仅能在嵌入到内核模块运行；这些特点Xenomai还保存着主要的目的是支持延迟利用，这里不做讨论。

更有趣的是Xenomai对Linux有1个共生的方法；例如，这个使它不同于RTAI/LXRT的实现。以此为目的，Xenomai线程不但能像基于内核的Xenomai线程运行在管线里最高优先级域（即，主要域）的上下文中，而且可以运行在常规Linux空间（即，次要域），即便经历更高的调度延迟，仍被Xenomai当作实时的。在Xenomai的术语中，前者被称为运行在主要履行模式，而后者处于次要履行模式。

为了对运行在次要域的线程提供完全的实时支持，Xenomai需要实现以下几点：

公共的优先级模型。只能调度，我们需要1种方法使实时核和Linux内核同享相同的优先级模型相对线程同享控制。换句话说，1个Xenomai线程需要是自己的优先级在任什么时候候严格生效，不管它当前的域，在所有的Xenomai线程中。Xenomai采取称为根线程可变优先级的技术，通过这个Linux内核自动继承被实时核控制的Xenomai线程的优先级，这恰好产生在进入次要域的时候。实际上，这意味着当前运行在主要域的Xenomai线程没有必要抢占运行在次要域中的线程，除非它们的有效优先级确切更高。例如，上面的行动跟RTAI/LXRT相反，在RTAI/LXRT中线程迁移到Linux空间事实上会丢失它们实时有限级，通过继承RTAI调度器定义的最低优先级实现。也就是说，常规Linux任务队Xenomai1无所知，这仅仅产生在属于SCHED_FIFO的类中，当与来自主要域的Xenomai线程竞争CPU时总会被抢占，即便他们依然会与运行在次要域中的Xenomai线程竞争优先级明智。
程序履行时间的可预测性。当1个Xenomai线程运行在Linux（即，次要）域，不管履行内核还是利用代码，它的时序不应当被非实时的Linux中断活动搅动，通常来讲被任何低优先级、产生在内核层的异步异步活动。1个简单的方法来禁止后者产生的概率是当Xenomai线程运行在Linux域时使Linux内核保持中断饥饿，因此没有推延处理睬在这段时间内触发上半部中断处理。使Linux内核遭受中断饥饿的方法是当内部需要中间Adeos域的时候阻塞他们，坐在被实时核和Linux内核占用的中断之间，在Xenomai术语中叫做中断屏蔽。不管甚么时候Xenomai线程在Linux内核空间被调用这个屏蔽都会被占用，在其它的情况下不同。需要注意的是屏蔽支持能被启用/禁用在每一个线程基础上，或在Xenomai构建时系统范围的基础上；默许情况下对Xenomai是被禁用的并且不是内建的。
细粒度的Linux内核。为了从次要履行模式中取得最好，我们需要Linux内核表现出最短的可能非抢占部份，因此在Xenomai线程运行在次要域变成准备运行以后重调度的机会会尽快的被捉住。另外，这确保了Xenomai线程能在1个短的和有时间界的1段时间内从主要域迁移到次要域，由于这个操作包括了到达1个内核重调度点。由于这个，

2.2. 系统调用盗取

由于Xenomai实时API（即，skins）可以堆积在Xenomai的nucleus上，能将它们自己的1组服务导出给用户空间Xenomai线程，必须有1种方法对适当的处理程序的分离对应的系统调用，而常规的系统调用都是在1起的。Xenomai拦截每个Xenomai线程需要处理的Xenomai或Linux域的系统调用圈套/异常。这通使用适当的Adeos定阅事件处理程序实现。Xenomai使用这类能力来：

（1）将来自利用程序要求的实时服务分发给恰当的系统调用途理程序；

（2）确保每个系统调用都会在其相应的域中履行，不管是Xenomai还是Linux。

2.3. 中断传播

由于实时nucleus在管线的最前面，当有感兴趣的中断来临时在Xenomai域中的实时nucleus会第1个被通知，中断被处理以后，nucleus会将该中断标记并传递到管线，如果必要终究会传递到Linux内核域。当被产生的中断唤醒时，实时nucleus会在外部中断处理程序返回后（以防中断堆积）重新调度，并会转换成它控制的可运行线程的最高优先级。

当没有实时活动被阻塞时，Xenomai域会将CPU的控制权交给中断屏蔽域。也就是说当Xenomai域空闲时让出CPU，当Xenomai有事件处理时，抢占CPU。对中断通过管线，Adeos有两种传播模式：隐式模式和显示模式。隐式模式由系统自动传播中断，显示模式需要手动传播中断。

3. 技能和诀窍

3.1 启用/禁用中断源

除能完全延迟1个域使不再有中断能经过它，直到它被明确的撤消延迟，Adeos允许在硬件层选择性的禁用/重启用中断的实际源。

接收了这个盒子后，Adeos处理所有域的中断制止的要求，包括Linux内核的和实时核的。这意味着在硬件PIC层禁用中断要求源，并锁住从这个中断源到当前域在管线层的任何中断的分发。相反的，启用中断意味侧重新激活PIC层的中断源，并允许从这个源到当前域的进1步分发。因此，1个想启用1个中断源的域必须是与制止这个中断源的域是同1个，由于这样的操作是域独立的。

实际上，这意味着，成对使用时，rthal_irq_disable()和rthal_irq_enable()服务集成了构成了Xenomai基础的实时HAL内相干Adeos的调用，必须由同1Adeos域解决。例如，如果1个实时中断处理程序用rthal_irq_request()服务于某个中断源连在1起，禁用中断源使用rthal_irq_disable()，那末这个源将会被Xenomai域阻塞直到同1中断源的rthal_irq_enable()被同1域调用。处理这个要求失败将会致使受影响的中断通道永久性丢失。

3.2. 域间同享中断

1个在域间同享硬件中断时误用Adeos管线的典型例子以下：

void realtime_eth_handler (unsigned irq, void *cookie) { /* * This interrupt handler has been installed using * rthal_irq_request(), so it will always be invoked on behalf of * the Xenomai (primary) domain. */ rthal_irq_disable(irq); /* The Xenomai domain won't receive this irq anymore */ rthal_irq_host_pend(irq); /* This irq has been marked as pending for Linux */ } void linux_eth_handler (int irq, void *dev_id, struct pt_regs *regs) { /* * This interrupt handler has been installed using * rthal_irq_host_request(), so it will always be invoked on * behalf of the Linux (secondary) domain, as a shared interrupt * handler (Linux-wise). */ rthal_irq_enable(irq); /* * BUG: This won't work as expected: we are only unlocking the * interrupt source for the Linux domain which is current here, * not for the Xenomai domain! */

在上面的这个不工作的例子中，由于Xenomai对所有截获的中断总是使用显示的传播模式，接下来的以太网将会在Xenomai日志中被标记为阻塞，等待Xenomai处理程序可能手动的将它传播给Linux。但是由于中断依然被Xenomai锁在管线层（别忘了实际上没有人从Xenomai域解决了期望的rthal_irq_enable()），这样的是不会产生的，由于Xenomai处理程序直到锁被移除才会运行的。因此，我们庆祝吧。

荣幸的是，对适当的同享中断有个方法，域间需要保持中断源禁用直到终究处理结束（例如，处理电平动身的中断是其中的1个问题）：实际上，你不需要做任何事情，由于在把它传递给管线之前Adeos已屏蔽了来自PIC层的进来任何中断。因此，你仅仅需要处理你看到的合适相干域处理程序的中断，并肯定在最后1个的时候使用rthal_irq_enable()来重启用中断源。不管什么时候Linux内核是那些接收者之1，常规的内核处理程序将会自动重启用，所以基本上你只需要担心在处理程序中调用rthal_irq_enable()，这个函数不会传播传进来的中断到Linux内核。

特别的在x86体系结构上，由于性能缘由，Adeos接收到的时钟中断将不会被屏蔽。这就是说，中断源将不会是你想以任何方式禁用的，所以这不是个问题。

3.3. 中断同享和延迟

但是，当传播通过全部管线保持屏蔽1个中断源可能会增加延迟。

由于Adeos保证没有由于中断在任何域上堆积引发栈溢出的产生，并且由于它在动身中断处理程序之前会延迟当前阶段，在Xenomai处理程序中没有必要禁用中断源。相反你乃至会想重新启用它，这样行将产生的中断可以被立刻记录下来，并且在当前处理程序调用返回后回立即被处理。

所以，解决方法是以这类方法重写先前的例子，以下：

void realtime_eth_handler (unsigned irq, void *cookie) { rthal_irq_enable(irq); rthal_irq_host_pend(irq); /* This irq has been marked as pending for Linux */ } void linux_eth_handler (int irq, void *dev_id, struct pt_regs *regs) { /* process the IRQ normally. */ }

4. 结论

Adeos是相当简单的1段代码，如果使用得当包括了许多有趣的属性。Adeos模型的主干是时间管线，正因如此，它提供了所有我们在Xenomai中需要的重要特点：

可预测的中断延迟；
精确中断虚拟化控制（每一个域和每一个中断处理程序注册，每一个域和每一个CPU的中断屏蔽）；
统1、优先级和面向域的事件传播模型；
1个通用和简单的API来简化客户代码的移植。

Xenomai使用这些特点来寻求Linux内核带来的实时服务的最大可能的集成。Xenomai的主要模式在最低的微秒即的延迟提供真的实时性能。另外，Xenomai在Linux未来演变中赌注，来改良内核的整体粒度，例如PREEMPT_RT，因此次要模式仍在在肯定意义上的实时，即便是最坏情况下的延迟也是可测的。这就是为何Xenomai从第1天开始就努力工作来到达与Linux内核高度集成的层次。斟酌共生，寻求共利。

5. 链接

Karim Yaghmour's Adeos 提议: http://www.opersys.com/ftp/pub/Adeos/adeos.pdf
乐观中断保护: http://citeseer.nj.nec.com/stodolsky93fast.html
GNA上的Adeos工作目录: https://gna.org/projects/adeos/
下载最新的Adeos补钉: http://download.gna.org/adeos/patches/
Adeos API 参考手册: http://home.gna.org/adeos/doc/api/globals.html

------分隔线----------------------------

上一篇 在线支付技术

下一篇 搭建latex编辑环境(ubuntu14.04安装latex的支持包texlive和编辑器texworks)

------分隔线----------------------------