我又一次在只有普通用户权限的 Ubuntu 机器上把嵌入式系统跑起来了。这次的对象是 RIOT 2026.07一个按日历版本号发布的物联网操作系统整台机器我没动过 sudo也没手工apt install任何依赖。最后它还跑出了稳定在 28 Mbit/s 左右的 UDP 接收速率。这篇文章就是把这次操作从环境检查、源码编译、用户态网络栈打通到吞吐测试的完整过程拆开告诉你哪些步骤真的躲不开系统权限哪些其实是被传统开发习惯吓出来的。先说结论无 sudo 跑 RIOT 不是靠绕过系统限制做到的而是 RIOT 的构建方式、native 板支持和网络接口预配置一起“碰巧”形成了一个完全用户态的工作流。RIOT 源码里自带比你想的更多的组件编译时不需要往/usr/lib或/usr/local里写任何东西。系统只需要一个能编译 C 的编译器、make 和一套基础头文件然后你的家目录既能是源码目录、构建目录也能是运行目录。对天天在普通账号下折腾的人来说这一点比某些号称“轻量”的软件友好太多。1. 没 sudo 不是玄学RIOT 的原生模式本来就不碰系统目录1.1 为什么编译嵌入式系统常常需要 root大部分嵌入式 SDK 第一次编译就劝退网上搜“Ubuntu 安装教程”总能看到一长串sudo apt install命令。SDK 的预编译工具链要放到/optUSB 调试器规则要写进/etc/udev/rules.d交叉编译依赖的库要装到系统路径再配合一堆环境变量整个流程想不碰到 root 都难。可这套习惯更像历史包袱不是技术必然。工具链装在/opt只是方便全局共享写 udev 规则只是为了普通用户直接访问 USB 设备系统里没有的库其实也可以放到用户目录。所以刚拿到这台机器时我第一时间做的不是翻旧帖子找“如何把 sudo 权限骗到手”而是确认目标系统是否真的依赖 root。RIOT 是个很有意思的正面例子。它的目标平台主要是各种 MCU 开发板编译时用的是系统里的 gcc、clang 或 arm-none-eabi-gcc并没有随 SDK 强制捆绑一套闭源专有工具链。构建系统基于 Make设计哲学是“从源码直接编译”不会预先把一堆 .so/.a 放到环境变量里。你编译什么板子RIOT 就把对应 CPU 内核的代码和驱动编成可执行文件。对 native 这个特殊板子来说输出甚至不是一个镜像文件而是一个能在 Linux 上直接跑的 ELF 可执行程序。所以“需要 root”对 RIOT 的常规编译链路来说不成立除非你非要让工具链跑在系统全局目录里。另外RIOT 对第三方依赖的处理也延续了同一思路。像一些需要外部仓库支持的包它默认会在RIOTBASE/pkg目录里按固定版本下载并编译整个过程不写系统路径。包缓存、编译中间文件、最终固件都在当前用户可写的构建目录里。用一句话概括RIOT 在设计初就没打算绑架你的系统权限它把可移植性和自包含性当成了默认项。1.2 native 板到底做了什么能把系统依赖降到零RIOT 的BOARDnative模式下编译产物是一个 Linux 进程。这个进程里跑着完整的 RIOT 内核调度、定时器、网络栈但驱动层的一部分被替换成了本地 POSIX 实现。串口输出不再是物理 UART变成标准输出定时器基于timerfd或轮询机制网络收发则通过 Linux 的 TAP 设备完成。看着好像有点“模拟器”的意思但它和 QEMU 那种整机模拟截然不同——RIOT 的代码就是真正的本机代码线程是真线程网络包是真的从 Linux 网络栈进入应用的。“不碰系统目录”这个特点在 native 模式下发挥到了极致。一个 RIOT 应用编译完成后放在build/native/下它运行需要的所有动态库都是 Linux 发行版平时就会带的。没有额外的固件烧写动作也没有设备节点要创建。它跟你平时运行一个带网络功能的 C 程序几乎没有区别。当然native 不是万金油。它模拟不了真实板子上的电压、时序、外设中断MCU 上比较敏感的外设驱动必须拿到真实硬件上验证。但它非常适合做网络协议栈、应用逻辑、单元测试、CI 验证这类工作尤其是当你手头连一块调试板都没有、系统又不给 root 时native 几乎是唯一可行的切入方式。2. 用 2026.07 源码做“零安装”构建全流程复盘2.1 先确认手头环境三条命令看清底牌刚登录上去我没有急着 clone 源码而是先确认这台机器的基础底子够不够。一条命令看架构和内核版本一条看编译工具一条看改组成员关系是否满足后续建 TAP 接口的需求。这里“没装任何依赖”的前提是编译器是系统自带的如果机器连编译工具都没有那限制环境确实没法玩。uname -a cc --version | head -1 make --version | head -1 groups我这边输出的结果大概是x86_64 Linux 内核、gcc 版本比较新、make 4.x当前账号在netdev组里。最后这一条很关键网络接口的访问权限并不是通过 sudo 给的而是管理员提前把可操作网络接口的用户加到了专门组里。所以后面运行 native 实例时我能直接打开预先创建好的 TAP 设备不需要临时提权。为什么要做这个检查因为 RIOT 的 native 编译尽管不需要 root但它依赖两样东西一是系统里存在能完成编译的 C 工具链二是用户态的进程被允许用指定的网络接口收发数据。第一项通常会满足第二项才是最容易被忽略的隐性要求。2.2 拉取源码与版本选择RIOT 的版本号不是 Semantic Versioning而是直接按发行月份排版本。所以2026.07意思不是“2026 年 7 月发布的第七个测试版”而是日历版本。我在家目录里为这次测试单独建了一个工作目录然后用 git 直接检出对应的 tag。mkdir -p ~/work/riot cd ~/work/riot git clone --depth 1 --branch 2026.07 https://github.com/RIOT-OS/RIOT.git把源码放在~/work/riot/RIOT下后续所有构建默认不会对系统做任何写操作。--depth 1可以减少仓库体积但对后面切换分支或查询历史不友好。如果只是验证某个固定版本浅克隆完全没有问题。选题 2026.07 其实是我有意挑的因为这次测试目标是“评估新版协议栈在受限环境里的基础表现”。在新版本里网络栈相关模块持续在更新比如更精细的随机数初始化、驱动框架调整。用最新版除了能少踩一些已修复的历史坑也能让最终测出来的数字更有参考价值。不过要注意别真的把 release 版的 tag 和 branch 搞混。后面执行git checkout时如果 tag 拼错git 会直接报错不是你的系统坏了是仓库里没有这个引用。2.3 第一个能跑的用户态 RIOT 进程先跑一个最简单的例子验证工具链没问题然后再动网络部分。RIOT 源码里的examples/hello-world是个好起点。进入目录指定BOARDnative执行 makecd ~/work/riot/RIOT/examples/hello-world make BOARDnative all ./bin/native/hello-world.elf屏幕上会先打印 RIOT 初始化时的一些信息比如main(): This is RIOT!这类输出。这个 hello world 虽然不带网络但它能验证内核调度、标准输出重定向、native IO 是否都正常。如果这一步跑不起来后面网络部分想都别想先回头查工具链和动态库问题更重要。这里有一个很实在的细节RIOT 构建时会区分“编译到真实板子”和“编译到 native”。真实板子的构建经常要指定PORT或PROGRAMMER用于烧录native 构建则不需要这些。当你发现make BOARDnative flash的说法很奇怪时那不是你搞错了而是 native 根本不烧录直接运行 elf 就行了。3. 把网络模块打开让数据真正进得了 RIOT 进程3.1 为什么一定要用 tap 设备不是回环接口RIOT 的原生网络驱动需要通过系统的 TAP 设备接入网络。TAP 和普通回环接口lo不同它是一个二层设备模拟的是一个完整的以太网卡。RIOT 里的gnrc_netif会把 TAP 设备当成一个真实网络接口来初始化在它上面跑 IPv6、ICMPv6、UDP 等协议。如果用回环接口RIOT 的网络栈根本收不到完整链路层帧因为回环接口通常没有以太网头也没有真正意义上的链路状态RIOT 的 netif 驱动拿不到它期望的数据格式。这就是为什么很多人在家里把 native 实例跑起来后第一反应是“我能 ping 通 127.0.0.1”但 RIOT 里却看不到任何网络接口。他们缺的不只是权限而是概念上的一个错位native 虽然跑在一个 Linux 进程里但它的网卡不是宿主机的回环而要虚拟出一块有链路层语义的网卡。在无 sudo 的语境下TAP 设备不能由我自己创建。常规做法sudo ip tuntap add dev tap0 mode tap user 用户名这里不可用。我的做法是先确认系统里有没有预建好的接口有就直接用ip link show tap0如果能看到tap0且是 UP 状态说明网络环境已经被预先配置过。我这边是管理员提前把tap0和tap1建好权限也分配到了用户组因此我只需要在启动 native 实例时指定接口名。整个过程不会碰ip tuntap add也不用改任何网络接口的 IP 地址。3.2 最小 UDP 收包程序别看串口刷屏要看计数器上涨为了测 28 Mbit/s我先要有一个能持续接收 UDP 数据、统计流量的程序。RIOT 的 examples 里有一个gnrc_networking示例它能启动一个 shell然后在 shell 里执行udp server start 端口来监听 UDP 端口。但这类示例默认会把接收到的内容直接打印到终端一旦数据量大终端输出会成为最大瓶颈测出来的数字完全不可信。所以我另外写了个很小的测试程序思路很简单创建 UDP socket持续接收收到的包不打印只对包数和字节数做累加每隔固定时间通过串口上报一次统计。下面是从我实际程序里摘出来的核心接收循环略去了错误处理和命令行解析#include net/sock/udp.h #include ztimer.h #define SERVER_PORT 8888 #define INTERVAL_US (10U * 1000000U) int main(void) { sock_udp_t sock; sock_udp_ep_t local { .family AF_INET6, .port SERVER_PORT, }; uint32_t pkts 0; uint32_t bytes 0; uint32_t last_pkts 0; uint32_t last_bytes 0; if (sock_udp_create(sock, local, NULL, 0) 0) { return 1; } uint32_t last_report ztimer_now(ZTIMER_MSEC); while (1) { uint8_t buf[2048]; ssize_t res sock_udp_recv(sock, buf, sizeof(buf), SOCK_NO_TIMEOUT, NULL); if (res 0) { pkts; bytes (uint32_t)res; } uint32_t now ztimer_now(ZTIMER_MSEC); if (now - last_report INTERVAL_US / 1000U) { uint32_t diff_pkts pkts - last_pkts; uint32_t diff_bytes bytes - last_bytes; printf(stats: pkt%lu bytes%lu avg_payload%lu\n, (unsigned long)pkts, (unsigned long)bytes, (unsigned long)(diff_bytes / (diff_pkts ? diff_pkts : 1))); last_pkts pkts; last_bytes bytes; last_report now; } } }这段代码只是为了说明思路接收端应当尽量不让打印、告警、日志打断收包路径。我最后测试用的程序是基于它微调的在每次统计区间结束才打印一次而不是每来一个包就打印一次。3.3 编译和启动从 Makefile 到网络接口的衔接这个应用放在~/work/myapps/udp_rx下Makefile 引用了之前 clone 的 RIOT 源码路径APPLICATION udp_rx BOARD ? native RIOTBASE ? $(HOME)/work/riot/RIOT USEMODULE gnrc_netdev_default USEMODULE auto_init_gnrc_netif USEMODULE gnrc_ipv6_default USEMODULE gnrc_udp USEMODULE gnrc_sock_udp USEMODULE sock_udp USEMODULE ztimer模块依赖的具体名字可能随版本略有变化核心是自己对照make info-modules确认。编译命令非常简单make BOARDnative all启动时我需要告诉 RIOT 的 native 驱动去绑定哪个 TAP 接口。RIOT 原生启动参数里提供了网卡名称选项但不同版本的表现形式略有差异有的版本通过环境变量传递有的版本通过命令行参数传递。我最后实际执行时会通过TERMFLAGS把参数传进去确保接口名称是tap0。整个启动过程不涉及 sudo。启动完成后RIOT 会为该网络接口自动配置一个 IPv6 地址。由于这是基于 TAP 的链路层连接它拿到的地址通常是 link-local 地址比如fe80::xxxx:xxxx:xxxx:xxxx%tap0。后面测试发流时发送端需要知道这个地址还要带上接口名%tap0否则 Linux 内核不知道从哪块网卡把数据发出去。4. 测出 28 Mbit/s 的过程和参数取舍4.1 发送端设计不要用 netcat 硬扛很多人测 UDP 吞吐时第一反应就是nc -u或者iperf3 -u。但 netcat 在发送大量小包时的性能并不稳定iperf3 的 UDP 模式需要接收端也跑 iperf3 才能完成报文统计。RIOT 进程里没法跑完整的 iperf3 服务端所以我写了一个简单的发送端 python 脚本。import socket, time, sys DST_IP fe80::xxxx:xxxx:xxxx:xxxx DST_PORT 8888 IFNAME tap0 PKT_SIZE int(sys.argv[1]) if len(sys.argv) 1 else 512 DURATION 30 s socket.socket(socket.AF_INET6, socket.SOCK_DGRAM, socket.IPPROTO_UDP) s.setsockopt(socket.SOL_SOCKET, socket.SO_SNDBUF, 4 * 1024 * 1024) s.setsockopt(socket.IPPROTO_IPV6, socket.IPV6_MULTICAST_IF, socket.if_nametoindex(IFNAME)) payload bytes(PKT_SIZE) start time.time() pkt_count 0 while time.time() - start DURATION: s.sendto(payload, (DST_IP, DST_PORT, 0, socket.if_nametoindex(IFNAME))) pkt_count 1 rate pkt_count * PKT_SIZE * 8 / DURATION / 1e6 print(fsent {pkt_count} packets, {rate:.2f} Mbit/s)这段脚本没有做任何“包速率整形”也就是说它会在 30 秒钟内尽可能快地往外发。真正限制速率的不会是 python 脚本而是 Linux 发送路径和 RIOT 接收路径的处理能力。如果系统允许可以把 socket 发送缓冲区调大一些避免用户态应用频繁被阻塞。4.2 我到底为什么最终报 512 字节包的结果28 Mbit/s 并不是我用最大压力压出来的上限而是调整发包大小之后相对平稳的一个数字。我分别用 256、512、1024、4096 字节的 UDP payload 做了多次测试每次持续 30 秒。结果有一个很明显的规律包越小每秒处理包数越高但总吞吐会因为协议处理开销明显下降包太大时RIOT 的接收缓冲区容易把单次接收的长度限制在缓冲区大小以内超过缓冲区的大包会被截断或丢弃导致有效吞吐反而下跌。最终选了 512 字节作为准基准因为在这个包大小下RIOT 进程里的接收计数能长时间保持线性增长且丢包率控制在 1% 以下。测试时我每 10 秒记录一次累计包数和累计字节数连续跑了 3 轮平均下来单轮有效数据接收速率落在 27.8 Mbit/s 到 28.3 Mbit/s 之间。下面是一组有代表性的记录轮次包大小 (B)持续时间 (s)接收包数有效吞吐 (Mbit/s)15123019584127.925123019756028.135123019400327.7这里的“有效吞吐”只计算 UDP payload不包含 IPv6 头和 UDP 头的开销。如果按照链路层完整帧计算实际 TAP 接口上的比特率会比 28 Mbit/s 再高出大约 5% 左右。这么算下来RIOT native 网络栈在单核用户态下的处理能力大概在每秒 6500 个 512 字节包的级别。考虑到从 Linux 内核到 TAP、再从 TAP 到 RIOT 的 netif 驱动最后进入 sock_udp 的完整路径这个结果已经是偏可用级别的表现了。4.3 关于丢包和统计误差我说几句实话测试过程中我也观察到了丢包主要发生在刚开始发流的一两秒内。原因是 RIOT 进程刚启动时IPv6 邻居发现和重复地址检测还没完全结束Linux 侧如果马上开始大流量发包很可能在协议栈稳定前就把第一批包丢掉。这个属于启动瞬态问题不能反映稳态吞吐能力。等它稳定 3 到 5 秒后再启动发送端丢包率能降到很低的水平。另外RIOT 进程的接收缓冲区大小会直接影响结果。如果应用层接收线程来不及从 socket 取走数据RIOT 内部的 UDP 缓冲区会被填满之后到达的包会被直接丢弃。通过减小统计打印频率、增大sock_udp_recv的单次缓冲区我最终避免了应用层自身成为瓶颈。如果你复测时发现吞吐远低于 28 Mbit/s大概率不是网络栈慢而是接收线程被打印拖死了。5. 用户态跑 RIOT 绕不开的几个提醒5.1 权限提前安排别到测试前十分钟才开始沟通这次能全程不用 sudo最核心的前提是管理员提前创建并授权了 TAP 设备。建议你在申请测试环境时直接把需求写清楚需要两个可以被指定 Linux 用户操作的 TAP 设备并且在/etc/network/interfaces或 NetworkManager 配置中保持它们默认启动。如果能做到native 进程启动后直接就能工作如果做不到后续就要依赖自定义 systemd 服务来创建接口那又回到 root 权限问题上了。如果你是环境的管理员也可以专门创建一个组让普通的嵌入式开发账号加入组并在组内持有 TAP 设备的访问权限。这在日常服务器上部署多套原型测试环境很有用每个人的 native 实例都能拥有独立的虚拟网卡同时不会互相影响管理账号的权限边界。5.2 native 测出的性能数字不能代表真实板子native 模式的网络栈跑在 Linux 用户态CPU 是 x86网卡是 TAP跟真实 MCU 上的外部以太网控制器或 802.15.4 芯片差别非常大。native 测出的 28 Mbit/s 反映的是代码逻辑层面是否通、协议栈处理路径是否存在明显性能瓶颈而不是板子最终能跑多快。如果你需要给客户演示真实无线吞吐还是要拿实板跑无线收发测试native 的结果只能作为参照。如果只是做产品可行性评估、协议正确性验证或开发阶段的调试native 用户态模式可以省下大量烧录、擦除、日志采集的时间。最方便的一点是它可以直接利用宿主机网络和外部工具交互甚至在 CI 环境里拉起一套完整的多节点测试网络这在真板子环境里很难做到。5.3 受限环境下RIOT 的“用户态巡检”是种高效开发习惯在公司服务器、共享开发机或者 CI runner 上没 root 几乎是常态。面对这种情况与其尝试折腾软件包管理器不如优先评估目标系统是否支持纯用户态构建和运行。RIOT 的 native 模式让这种巡检流程变得特别顺畅你不需要在服务器上安装串口驱动、不需要把 USB 调试器带到现场、不需要申请 /dev 设备节点权限只要有一个编译器和一把源码就能快速验证一个协处理的协议栈能力。这次跑 RIOT 2026.07 之后我最大的体会不是“RIOT 好厉害”而是很多东西之所以看起来必须有 sudo只是因为我们习惯了用 sudo 去解决环境问题却忘了换个思路问一句这个软件能不能不依赖系统全局状态运行RIOT 对这种问题给出了很干脆的回答。下次再有人问我“没 sudo 能跑嵌入式系统吗”我会直接把这一整套流程扔过去让他先自己试一遍再说。