Xenomai 4 这个名字，圈内人确实等了不少时间。如果你用过 Xenomai 3 的 Cobalt 核，会知道那套"双内核"思路在工业实时控制里有多能打；如果你维护过它的工程，也会知道维护 I-pipe（中断管道）内核补丁有多痛苦。Xenomai 4 把底层核心换成了 EVL core，把中断虚拟化的实现从 I-pipe 换成了 Dovetail，表面上还是"跟 Linux 抢时间"的老路线，实际上从内核补丁、API 到调度模型都推倒重来了一遍。这篇文章不打算念官方文档，我按自己从 Xenomai 3 迁移过来、把一个运动控制 demo 跑在 Xenomai 4 上的实际经历，聊聊 EVL 和 Dovetail 到底解决了什么、开发环境怎么搭、以及最容易踩的坑。
1. 从Cobalt/Mercury到EVL：Xenomai 4为什么敢推倒重来
1.1 实时性的本质：Linux 到底差在哪
先说清楚一个前提：Linux 不是不能做实时，而是它的"实时"是统计意义上的软实时。普通内核里，一个高优先级线程唤醒后到底多久能跑到，取决于太多变量——中断优先级、spinlock 持有时间、调度器 tick、甚至同一个 CPU 上的 cache 竞争。系统可能平均 50 微秒就响应了，但最坏情况下几百微秒甚至毫秒级延迟也不是没可能。
硬实时系统看的恰恰是最坏情况（worst-case），不是平均值。运动控制里一个 1kHz 的伺服周期，如果某一拍延迟超过 200 微秒，可能直接导致轨迹偏差；工业总线的错误帧倒计时更狠。所以才有两类主流方案：一类是给 Linux 打 PREEMPT_RT 补丁，另一类就是 Xenomai 这类双内核方案。
PREEMPT_RT 的思路是让内核处处可抢占、把不可延迟路径尽量缩短。它仍然是"Linux 独占整机"，实时性上限完全取决于内核代码里还剩多少坑。双内核方案则更"霸道"：在 Linux 旁边放一个实时核，硬件中断先经过实时核，实时核判定这个中断是自己的还是 Linux 的，只有 Linux 的中断才被"注入"给 Linux。普通 Linux 程序该怎么跑怎么跑，但实时任务跑在实时核上，拥有最高优先级的中断入口和调度权。
1.2 Xenomai 3 的遗产：Cobalt 与 Mercury
Xenomai 3 提供两种运行模式。Cobalt 是真正的双内核，依赖 I-pipe 把 Linux 中断"截流"，在上面实现了一个功能很完整的实时内核，而且通过 "skin" 层提供 POSIX、VxWorks、pSOS、uITRON 等一堆 API。Mercury 则不做双内核，直接运行在带 PREEMPT_RT 的普通 Linux 上，API 走的是普通 syscall。
Cobalt 的能力没得说，但问题也很明显。第一是 API 太重，skin 层为了兼容老实时系统保留了大量历史包袱，学习成本高。第二是 I-pipe 这个补丁太大、太侵入，它几乎改到了内核的每个角落，内核迭代一次，I-pipe 就要跟着大改一次。第三是调试困难，双内核模式下，实时核和 Linux 共用一套硬件资源，出问题的时候很难判断是哪一侧的锅。
Mercury 虽然不用 I-pipe，但它的实时上限就是 PREEMPT_RT 的上限，等于放弃了双内核带来的最坏情况保障。所以 Xenomai 3 其实是"要么强大但难维护，要么好维护但不强大"的二选一。
1.3 Xenomai 4 的选择：EVL + Dovetail
Xenomai 4 的定位，一句话概括：保留双内核实时能力，但把整个实现做"薄"。
EVL core 是新一代实时内核核心，它不再搞 Xn skin 那套多 API 兼容层，而是提供一套紧凑的、偏 POSIX 风格的 C API，叫 libevl。Dovetail 则是替代 I-pipe 的中断流水线补丁，目标是让 Linux 内核同时具备 "in-band"（带内）和 "out-of-band"（带外）两级执行环境，EVL 的实时线程跑在带外，普通 Linux 跑在带内。
说白了，Xenomai 4 想解决的不是"实时性不够"——Cobalt 早就证明了实时性够——而是"这套东西能不能活得更久、更容易跟上 Linux 内核的演进、更容易被新项目接受"。Dovetail 的补丁量比 I-pipe 小一个数量级，这是它的核心卖点。
2. Dovetail中断流水线：从"总机接线员"到"快递分拣线"
2.1 I-pipe 为什么难用
I-pipe 的名字是 Interrupt Pipeline，思路是在硬件中断和 Linux 内核之间加一条"管道"。所有中断必须先进入管道头部，由管道决定这个中断要发给哪个客户。这个客户可以是 Linux，也可以是 Cobalt 的实时处理程序。
问题在于，I-pipe 的管道是串行结构，而且为了维护优先级，在实时处理程序运行期间，整个管道都会被"冻结"——所有其他中断都被挡在管道外面。在实时任务密集的单核系统上，这会拖慢 Linux 侧的中断响应；在多核系统上，跨 CPU 的中断和 IPI 也会挤在这条管道里。
更麻烦的是，I-pipe 对内核的改动近乎无孔不入。它需要拦截中断、syscall、page fault、信号等几乎所有内核入口点，而且这些拦截点散布在各个架构的汇编代码里。每次 Linux 发布新内核，I-pipe 的移植团队都要花费大量精力重新适配。这也直接导致 Xenomai 能跟踪的内核版本总是滞后。
2.2 Dovetail 的两级流水：out-of-band 与 in-band
Dovetail 保留了"管道"这个概念，但设计思路完全变了。如果让我用一个更直观的比喻，它更像一条快递分拣线：每个 CPU 上有一条中断流水线，流水线上有两个"分拣口"，第一个分拣口是 out-of-band（带外），第二个是 in-band（带内）。
硬件中断到达后，先经过带外分拣口。如果 EVL core 在这个中断号上注册了带外处理函数，那就直接在这里处理完，Linux 完全不知道这件事。如果没有带外处理函数，中断就被"放行"到带内分拣口，进入 Linux 正常的 request_irq 处理流程。
这里最关键的一点是：Dovetail 不是把 Linux 的中断处理"包"起来，而是把 Linux 的内核入口"分层化"。带外代码运行的时候，Linux 侧的中断、调度、软中断都可以被合理地推迟，但 Dovetail 不会粗暴地屏蔽整个 CPU 的中断。它用一套经过精心设计的同步原语（比如 per-CPU 的 pipeline state、oob stall 标志）来保证两侧不会互相踩踏。
2.3 Dovetail 不止管中断
这是很多人忽略的一点：Dovetail 拦截的不仅仅是 IRQ。为了使 EVL 线程能够真正"带外"运行，它还必须处理 syscall 入口、page fault、信号、RCU 读锁等一连串内核事件。EVL 线程在带外运行时，如果要访问用户态内存触发了缺页，Dovetail 需要让这个缺页事件从带外"降级"到带内处理，否则实时线程就可能带着锁去缺页，造成不可控延迟。
换句话说，Dovetail 是一条横贯内核事件的流水线，中断只是其中最频繁、最关键的乘客。也正因如此，它的补丁虽然比 I-pipe 小，但依然会触及 arch 底层的 entry 代码，只是触达方式更集中、更模块化，维护起来轻松很多。
2.4 补丁量变化带来的实际收益
我印象中，I-pipe 针对一个内核版本的补丁经常是几万行级别，而 Dovetail 的 core 补丁大概只有几千行。数字不用纠结，重点是维护模型的改变：I-pipe 是"外科手术式"地把一个完整子系统塞进内核，Dovetail 则是"加一层薄薄的分流器"。这个差异直接影响你对内核版本的选择——Xenomai 4 跟进新内核的速度明显比 Xenomai 3 时代快，这对要上新产品的人来说是实打实的利好。
3. EVL核心的架构与编程模型：从"引经据典"到"够用就好"
3.1 EVL 在系统里的位置
EVL core 是一个运行在内核态的实时核，它的代码量比 Cobalt 小很多，但职责非常明确：管理带外线程的调度、时钟、定时器，以及提供进程间通信原语。
它不是一个独立操作系统，它的存在高度依赖 Linux：EVL 线程的完整上下文（虚拟内存、地址空间、打开的文件等）依然是 Linux 的，只是它的执行时机和调度由 EVL 的调度器接管。用一句直白的话讲：Linux 提供"身体"，EVL 接管"大脑"里跟时间最敏感的那部分决策。
EVL core 本身是作为内核模块还是编译进内核，取决于你用的构建方式。它对外暴露一个主设备节点，我记得是 /dev/evl，用户态程序通过 ioctl 与它通信。当然，libevl 把这些细节都封装好了，绝大多数时候你不需要直接碰 ioctl。
3.2 线程模型与调度策略
EVL 线程的创建方式有两种：一种是从普通 Linux 线程"升级"上来，调用 evl_attach_self()，让当前线程进入 EVL 的调度域；另一种是直接调用 evl_create_thread() 创建新的 EVL 线程。无论哪种方式，线程创建后都拥有一个名字，这个名字在 /dev/evl 下会有对应的资源项，方便调试。
调度策略上，EVL 提供几种：
- SCHED_FIFO：经典优先级抢占调度，实时线程最常用的模式。
- SCHED_TP：时间分区调度，可以在多个实时任务之间固定分配 CPU 时间比例，适合有混合关键性需求的项目。
- SCHED_QUOTA：配额调度，给一组任务设定带宽上限，防止某个失控任务把 CPU 吃满。
3.3 一个最小例子：周期线程
我最初跑通 Xenomai 4 是在 x86_64 的 NUC 上，libevl 的版本大概是 0.9 左右。下面是我整理过的一个最小周期线程，代码不追求绝对完整，重点看模型的差别：
#include <evl/evl.h> #include <evl/thread.h> #include <evl/timer.h> #include <errno.h> #include <stdio.h> #include <time.h> static void rt_loop(void *arg) { struct timespec next; int ret; /* 让当前线程进入 EVL 调度域 */ evl_attach_self("rt-cycle"); /* 读取 EVL 维护的时钟 */ evl_read_clock(CLOCK_MONOTONIC, &next); for (;;) { next.tv_nsec += 1000000; /* 1ms 周期 */ if (next.tv_nsec >= 1000000000L) { next.tv_sec += 1; next.tv_nsec -= 1000000000L; } /* 这里放真正的实时任务逻辑 */ evl_printf("tick at %ld.%06ld\n", next.tv_sec, next.tv_nsec); /* 睡眠到绝对时间点，保证周期不漂移 */ ret = evl_sleep_until(CLOCK_MONOTONIC, &next); if (ret && errno != EINTR) break; } } int main(int argc, char *argv[]) { struct evl_thread *thread; int ret; ret = evl_create_thread(&thread, "rt-cycle", rt_loop, NULL, 90, 0); if (ret < 0) { perror("evl_create_thread"); return 1; } pause(); return 0; }这里有一个和普通 pthread 编程很不一样的点：周期线程使用绝对时间点来安排下一次唤醒，所以即使某个周期内处理逻辑偶尔多花了一点时间，调度器也会按照绝对时间线把线程推到下一个理论上应该执行的时刻，不会像相对延时那样越漂越远。
3.4 IPC 原语的实际用法
周期线程只是第一步，真实项目里线程之间必须交换数据、同步状态。EVL 提供的 IPC 对象虽然数量不多，但都踩在实时系统的痛点上：
- semaphore：经典计数信号量，用于任务间"发信号"的场景。
- mutex：优先级继承互斥锁。注意这里不带条件变量，因为条件变量在实时场景下容易被误用。
- monitor：EVL 特有的"事件化互斥量"，可以理解成 mutex + condition variable + broadcast 的组合，用于一对多唤醒。
- event flag：事件标志组，等待某个位掩码组合，适合状态机同步。
- xbuf：带外无锁环形缓冲区，专门用来在实时线程和非实时线程之间搬大数据，是"采集数据交给 Linux 去分析"这个场景的主力。
我自己的经验是，EVL 的 API 名称和 POSIX 很像，但语义会对齐到实时场景。比如 mutex 的等待方可以指定超时，避免实时任务被锁死了不报错。这种"少而精准"的 IPC 集合，第一眼可能觉得不够用，实际用了以后发现比 Xenomai 3 的一大堆 API 更容易设计出清晰的结构。
4. 搭建Xenomai 4环境：从内核补丁到跑通延迟测试
4.1 选内核版本与拿补丁
想跑 Xenomai 4，首先得有一个打上 Dovetail 补丁的 Linux 内核。Dovetail 会针对特定内核版本发布补丁，不要拿任意版本硬套。我当时选择的是项目维护的 dovetail 分支（比如基于 5.15 或 6.x 的长期稳定分支），用 git 直接检出，比手动打 patch 省心太多。
步骤大致是：
- 准备好一个支持 Dovetail 的 Linux 源码树。
- 把 EVL core 的代码编进去（或编成模块）。
- 编译内核，启动后确认 /proc 下能看到 Dovetail 和 EVL 相关节点。
- 编译安装 libevl，编译测试工具。
libevl 的构建方式很常规，我用的版本是 meson 工程，configure 之后 make && install 就可以，测试工具会在 build 目录下生成。如果你只是想快速评估，官方仓库里有现成的容器或脚本模板，但我的建议是自己在目标板子上完整走一遍编译流程，因为交叉编译和容器里碰到的工具链问题迟早会暴露。
4.2 关键内核配置项
这里放一张我自己写进项目文档的配置对照表，省得你踩我踩过的重复配置：
| 配置项 | 推荐值 | 说明 |
|---|---|---|
| CONFIG_DOVETAIL | y | 启用 Dovetail 中断流水线，Xenomai 4 的前提 |
| CONFIG_EVL | y | 编译 EVL core，如果做模块则后续 modprobe |
| CONFIG_HZ_PERIODIC | n | 周期 tick 会干扰带外实时线程，尽量关闭 |
| CONFIG_HZ_1000 | y | 在部分内核上可提高内带调度精度（视版本而定） |
| CONFIG_NO_HZ_FULL | y | 配合启动参数 nohz_full 使用，减少无谓 tick |
| CONFIG_RCU_NOCB_CPU | y | 将 RCU 回调转移到非实时 CPU |
| CONFIG_PREEMPT | y | 普通 Linux 侧保持低延迟 |
| CONFIG_SMP | y | 多核情况下 EVL 也可以多核并行 |
注意 CONFIG_EVL 如果编成模块，启动后要记得 modprobe evl，否则 /dev/evl 不会出现。我一开始就栽在这上面，模块没加载，程序一直报找不到设备节点。
4.3 启动参数与 CPU 隔离
实时延迟最关键的因素不在内核编译选项，而在启动参数。你要把实时任务所在的 CPU 从 Linux 的日常事务里"摘出去"。我常用的启动参数组合：
isolcpus=2,3 nohz_full=2,3 rcu_nocbs=2,3 irqaffinity=0,1含义是：CPU 2、3 留给 EVL 实时线程，Linux 的普通进程和调度器 tick 尽量别上去；RCU 回调和设备中断都赶去 CPU 0、1。IRQ 是最后一个要点，检查你实时线程要用的外设中断落在哪个 CPU 上，把中断亲和性手动设置到非实时 CPU。
我见过很多人在这一步翻车：内核编译全对了，latency 测试却总是会有几十微秒的尖刺，最后一查，网卡的中断和实时线程挤在同一个核上，网卡一忙就是一片尖峰。
4.4 跑通第一个延迟测试
环境起来后，先跑 libevl 自带的 latency 工具。以我手头版本为例，命令类似：
cd build/tests ./latency -p 1000 --cpu 2-p 1000 表示 1ms 周期，--cpu 2 把测试线程绑到 CPU 2。程序会周期性触发一个任务，记录实际触发时刻相对理论时刻的偏差，最后打印最小值、平均值和最大值。
第一次跑通的时候，我的 NUC 上平均延迟大概是 1 到 2 微秒，最大延迟 6 微秒左右。不要急着和网上那些 0.x 微秒的数据比，硬件的体质、BIOS 设置、中断负载不同，结果差一个数量级都正常。关键看两个指标：一是最大值是否稳定不漂移，二是是否频繁出现尖刺。
5. 从Cobalt迁移到EVL的实测经验：三个坑与一个建议
5.1 坑一：EVL 线程里调用 Linux 服务会"破功"
双内核方案有个冷酷的物理事实：EVL 线程在带外运行，它的"身体"还是用户态程序，一旦调用 open、printf、malloc 触页、futex 这类普通 Linux 服务，就会经历一次 in-band 迁移，也就是从带外"掉进"带内。
我最初跑周期线程，习惯性用 printf 打印调试信息，结果延迟表上立刻出现几百微秒的毛刺。后来改成 evl_printf（它直接走带外输出缓冲）才恢复正常。malloc 也一样，第一次访问新分配内存会触发缺页，这个缺页要被 Dovetail 转给 Linux 处理，延迟不可控。所以实时任务里如果要开缓冲区，务必在进入实时循环前提前分配并且触碰一遍（prefault）。
5.2 坑二：CPU 与中断不隔离，"平均值好看、最大值爆炸"
我第二次搭环境时偷懒，没有配置 isolcpus，只开了内核选项，latency 的平均值居然也还行，但最大值动不动就 50 微秒以上。后来用 perf 查了一下，是 kworker 和调度器的 housekeeping 扰动了 CPU。把 CPU 隔离配置加上后，最大延迟直接回到个位数微秒。
还有一次问题是板卡上某个驱动的轮询线程频繁产生 IPI，IPI 会穿过 Dovetail 流水线，如果在实时 CPU 上被处理，也会造成抖动。这种情况下要把 IRQ affinity 和相关线程的 CPU 亲和性都调到非实时核。
所以我的固定流程是：先看 /proc/interrupts 统计每个中断都跑到哪个 CPU，再决定隔离哪些 CPU，最后才跑延迟测试。跳过这一步的人，和当年 I-pipe 时代一样，依然会翻车。
5.3 坑三：Dovetail 和 PREEMPT_RT 不是同一个东西
很多刚接触 Xenomai 4 的朋友会问：Dovetail 是不是就是 PREEMPT_RT 的替代品？真不是。PREEMPT_RT 是让 Linux 内核自身变为可抢占，Dovetail 是给 Linux 加一条带外执行通道。两者面向的问题域不一样。
如果你的项目是"绝大多数时候延迟不错、偶尔一次 1ms 也能忍"，那是软实时，PREEMPT_RT 完全够用，没必要上双内核。如果你的项目要求硬化的最坏情况边界，比如抓拍系统、工业总线主站、飞行控制器，那才需要 EVL 这种带外通道。
我不建议为了拉低一个内部延迟指标而无脑上 Xenomai 4，双内核带来的调试复杂度是实打实的。先量化需求，再做技术选型，这比任何内核补丁都重要。
5.4 我的建议：用"最小实时核"的视角重新设计程序
最后说一点方法论。Cobalt 时代很多人习惯了"把整个应用塞进实时核"，因为 API 齐全、什么都能干。EVL 的设计哲学明显是反过来的：实时核只管最敏感的那一小段逻辑，其他事情全部交给普通 Linux 线程。
我现在的做法是：一个高优先级周期线程做采样和控制，通过 xbuf 把原始数据发给普通线程做分析、显示、日志；实时线程里不碰锁、不做 IO、不调用任何可能缺页的函数；所有配置在启动时一次性初始化好。这样写出来的程序不仅延迟稳定，而且排查问题的时候目标非常小——要么是实时线程的问题，要么是 Linux 侧的接口问题，不需要像以前那样在两套 API 之间来回猜。
另外还有一个小技巧：调试阶段给实时线程加上 deadline 工具或者在时间戳上打上序列号，看最大延迟对应的代码位置，比直接看平均值有用得多。我自己就是靠这个在驱动中断亲和性配错的时候，快速锁定了是网卡 IRQ 而不是调度器的问题。
