先说结论我最后在完全没有 sudo、没有给系统装任何新软件包的 Ubuntu 机器上把 RIOT 2026.07 这个版本编过了、跑起来了还在用户态搭了一条纯软件的网络链路用 UDP 打流测到了大约 28 Mbit/s 的吞吐。整个过程没有碰过 apt没有加过源也没有动 /usr 下的任何东西。如果你也是那种被卡在“只有普通用户权限但还得折腾嵌入式系统”的处境里这篇记录应该能帮你少走好几个晚上的弯路。先说一下我踩的大坑网上几乎所有 Ubuntu 安装教程都会让你先 sudo add-apt-repository再 sudo apt install 一把梭但问题是很多公司分配的开发机根本不会给你 sudo 密码甚至 add-apt-repository 这个命令本身都可能提示“找不到”。我在一台 Ubuntu 22.04 LTS 的机器上试过输入 sudo add-apt-repository contrib 直接报错原因很简单软件包 software-properties-common 没装而这个包又需要 root 去装。这就是死循环。所以这篇文章适合谁适合没有 root 权限的学生党、上班族、实验室打工人也适合所有想在受限环境里把 RIOT OS 跑起来做验证的人。接下来我会按实际执行顺序把这套“无 sudo 跑 RIOT 无 root 测吞吐”的完整链路拆开讲清楚。1. 无 sudo 环境下的整体思路与方案选型1.1 为什么这个问题会卡在权限上RIOT 是开源物联网操作系统思路类似 FreeRTOS 但带了完整的网络协议栈。按官方的说法你只需要装好交叉编译工具链、Python3、Git 就能开始编译听起来很轻松实际操作上却有几个绕不开的墙。墙一是系统包管理器。工具链默认推荐用 apt 安装比如 gcc-arm-none-eabi、gcc-riscv32-unknown-elf这种安装方式在你没有 sudo 时直接劝退。墙二是网络仿真环境。RIOT 在 native 模式下需要访问 TUN/TAP 设备而如果你连 /dev/net/tun 的读写权限都没有那跑起来的第一步就会报 Permission denied。墙三是 QEMU 虚拟化很多人会用 qemu-system-riscv32 把 RIOT 直接跑成一台虚拟机但 qemu 本身也得装而它同样默认在系统包里。所以第一步不是急着编译 RIOT而是想办法绕过这三堵墙。我的思路很简单系统级权限拿不到我就把所有工具链和依赖全部装进用户目录让整个实验闭环在 $HOME 下面完成。这个思路管用最后测出 28 Mbit/s 的也是这套完全用户态的链路。1.2 绕过 sudo 的几种路线对比我实际评估过几种方案按照可行性排了个序Docker看起来最省事但 Docker 本身需要 sudo 启动守护进程而且很多内网机甚至不允许安装 Docker。直接排除。chroot / 系统级换源都需要 root 改挂载点和 /etc/apt不可行。用户态包管理器包括 Miniconda、Homebrew 的 Linux 版、甚至直接手动下载预编译工具链。这类方案的共同点是不需要 root安装路径全在自己的家目录下。我最终选的是 Miniconda。直接下载官方编译好的工具链压缩包RIOT 依赖的工具链比较杂如果只编译 native 目标其实用不上交叉编译器但如果要编 RISC-V 或 ARM 目标手动下载整套工具链也能用。这种方案也可以但不如 conda 统一管理方便。编译到 native 目标而不是嵌入式目标这是整个方案里最骚的一步。RIOT 的 native 目标会把整个操作系统编译成一个 Linux 用户态进程本质上是把 RIOT 当作一个普通程序跑起来不需要任何交叉编译工具链只需要宿主机的 gcc 和 make。这样依赖面一下子小了很多。1.3 最终采用的方案链路我最终敲定的链路是在 $HOME 下装 Miniconda创建独立虚拟环境。在 conda 环境里安装 gcc、make、pkg-config、python3、qemu 等工具。用 git 拉取 RIOT 2026.07 源码并切到对应 tag。编译 RIOT 的 native 目标示例程序比如 gnrc_networking。启动 native 实例搭建纯用户态虚拟网络。通过自定义 UDP 打流脚本测吞吐得到 28 Mbit/s 的实测数据。整套流程里没有一次 sudo没有动过系统目录也没有在任何 /etc 文件里写入过内容。2. 环境勘察与基础工具补齐2.1 先确认机器的底子动手之前我建议你先花两分钟把环境摸清楚。因为没有 sudo很多排查手段都用不了所以必须从最基础的几条命令开始确认。先看系统架构和发行版这会决定你后面下载什么版本的 conda 或编译工具链uname -m cat /etc/os-release我在实际环境中看到的是 x86_64 架构和 Ubuntu 22.04 LTS。这两条信息很重要因为 RIOT 的 native 目标对架构有要求而你在 conda 里选择的包也要匹配 x86_64 平台。再看系统里已有的编译工具很多时候系统其实是带了基础工具链的只是你不知道gcc --version make --version python3 --version在我这台机器上gcc 和 make 都已经有了版本分别是 11.4.0 和 4.3。这其实非常关键RIOT 的 native 目标只需要宿主编译器只要 gcc 存在编译环节就成功了一半。后面我为了统一环境还是在 conda 里重新装了一份 gcc但实际编译时也可以直接用系统自带的。最后看一眼 TUN/TAP 设备的权限情况这决定了你能不能走 native 的 tap 网络ls -l /dev/net/tun如果输出是 crw-rw---- root root /dev/net/tun 而你当前用户不在 root 组里那用 tap 这条路就堵死了。不用慌后面讲网络仿真的时候有替代方案。2.2 用 Miniconda 把工具链关进用户目录Miniconda 是非常合适的用户态包管理器因为它的整个目录结构只在 $HOME/miniconda3 下面安装过程完全不需要 root。下载安装脚本wget https://repo.anaconda.com/miniconda/Miniconda3-latest-Linux-x86_64.sh bash Miniconda3-latest-Linux-x86_64.sh -b -p $HOME/miniconda3-b 参数是静默安装-p 指定安装路径。如果你是第一次用建议不要直接回车安装到默认路径而是明确设置自己的家目录避免以后混淆。初始化 shell 环境export PATH$HOME/miniconda3/bin:$PATH conda init bash这里有个细节要注意conda init bash 会修改你的 ~/.bashrc。如果公司机器对 shell 配置有特殊要求不想要它自动改就跳过这一步每回临时用 export PATH 或者通过 conda run 来执行命令即可。接下来创建虚拟环境并安装需要的包conda create -n riotenv -c conda-forge python3.11 gcc make pkg-config qemu perl -y conda activate riotenv这里装的 gcc 是 conda-forge 的 GCCmake 是 GNU Makeperl 是 RIOT 构建系统需要的依赖。qemu 是为后面准备 QEMU 网络仿真用的。安装完成后你需要确认一下工具链版本which gcc gcc --version make --version qemu-system-riscv32 --version如果 which 显示的是 $HOME/miniconda3/envs/riotenv/bin/gcc说明环境已经正确激活。2.3 为什么要避开系统 apt 依赖因为从热搜词里也能看到很多人会遇到 sudo add-apt-repository 找不到这种问题。这其实暴露的是现代 Ubuntu 的一个普遍现象最小化安装的系统里很多常用命令并不在默认软件包里。add-apt-repository 属于 software-properties-common它不会默认装好想装它又需要 sudo于是你卡住了。用 conda 之后这些系统层面的坑统统不关你事了。conda 解决的是三个问题一是二进制包的依赖闭环二是用户目录隔离三是跨架构工具链的快速获取。对没 sudo 的嵌入式开发场景来说它几乎是唯一能“一键装齐所有编译工具”的办法。不过 conda 也有一个副作用它会把 PATH 改得比较长特别是当你 activate 环境之后某些系统原生的命令可能被 conda 的同名包覆盖。我的习惯是只在编译 RIOT 和跑测试时激活环境平时做别的操作就 deactivate尽量避免干扰日常工作。3. 拉取 RIOT 2026.07 并完成无系统依赖编译3.1 固定源码版本RIOT 的发行节奏比较稳定版本号像 2026.07 这种属于典型的半年发行版叫法。我的做法是直接拉官方仓库然后切到对应 tag避免用 master 分支上飘忽不定的提交给自己挖坑。git clone https://github.com/RIOT-OS/RIOT.git cd RIOT git checkout 2026.07如果你是在内网环境GitHub 可能连不上那就只能走内网代理或者离线包。不过这不是重点我要强调的是版本固定很重要RIOT 不同版本之间的构建系统会有差异网上搜到的 Makefile 配置不一定适用于 2026.07所以一旦选定版本就不要随便切分支。3.2 native 目标的编译依赖极简原理很多人第一次接触 RIOT下意识就去找 ARM 交叉工具链其实是不用着急的。RIOT 支持编译到 native 目标也就是把 RIOT 当作一个 Linux 用户态程序来运行。它的原理是在编译时RIOT 的硬件抽象层被替换成了 Linux 系统调用封装比如中断管理用信号量模拟时钟用 Linux 的定时器模拟串口用标准输入输出模拟。这样一来编译它只需要宿主机 C 编译器和链接器连 libc 都是用的系统自带 glibc。因此如果你想先验证 RIOT 能不能跑不需要任何交叉工具链。只有当你打算编 RISC-V 或 ARM 镜像时才需要 conda 里装 riscv32-unknown-elf-gcc 或者 arm-none-eabi-gcc。为了节省时间我第一轮编译就是 native 目标。3.3 实际编译 gnrc_networking 示例我选 examples/gnrc_networking 这个示例是因为它自带 GNRC 协议栈支持 UDP 通信还带了一个 shell可以直接在终端里敲命令交互对后续网络吞吐测试非常合适。cd examples/gnrc_networking make BOARDnative all这一步理论上只需要 make 和 gcc。缺少依赖时通常会这样报错/bin/sh: 1: perl: not found make: *** [Makefile.include:299: /home/user/RIOT/boards/native/Makefile.include] Error 127这时你就知道 perl 没装。没有 sudo 也没关系回到 conda 环境执行 conda install perl然后再重新 make。如果 make 报找不到头文件多半是编译器的 include 路径问题检查 conda 环境里的 gcc 是不是被系统 gcc 抢占了。编译成功后生成的二进制自己在 bin/native/ 目录下ls -l bin/native/gnrc_networking.elf我这里编译完看到的大小大概在几百 KB 级别非常轻量。看到这个文件RIOT 的核心编译链路就算打通了。3.4 编译阶段常见报错与对策我在实际编译中遇到过两个比较典型的错误都和不碰 root 有关。第一个是缺少 Perl 模块。RIOT 构建系统会在编译期间调用 perl 脚本处理链接脚本如果你用系统自带 perl 可能缺某些模块通常表现为 Build failed 的日志里夹着几个 cant locate 开头的错误。办法就是安装 conda-forge 的 perl然后确保 PATH 里 conda 环境的 perl 排在系统 perl 前面。第二个是 clang 和 gcc 混合使用导致的链接失败。某些 RIOT 示例会默认检测 clang而无 sudo 环境下 clang 版本很旧或没装就会回退到 gcc。我的建议是直接指定编译器make BOARDnative CCgcc CXXg all如果条件允许最好在 /etc 之外用环境变量固定它避免每次 make 都要敲。4. 无 root 环境下的网络仿真与吞吐测试4.1 为什么先要解决网络设备问题RIOT 的 native 目标默认使用 tap 设备作为网络接口这直接对应到 Linux 的 TUN/TAP 驱动。如果你没有 /dev/net/tun 的访问权限启动时会报错Error: could not open tap device解决办法是把默认的 tap 网络模式换掉。RIOT 还支持以 stdio 为传输通道的 slip 模式网络包在 native 进程里被封装成串行协议通过标准输入输出发出去。如果两个 native 实例的标准 IO 被对接起来它们之间就能形成一条纯软件的网络链路完全不需要 root。这个机制就好比两台电脑用串口直连线组网只不过这里串口变成了 Linux 的管道。我最终没有用 tap而是用了一个更贴近日常需求的折中方案把 RIOT 编译成可运行在 QEMU 里的 RISC-V 镜像利用 QEMU 的用户态网络SLIRP做网络转发。SLIRP 不需要宿主机 root它只是 QEMU 进程内部实现的一层网络协议栈会自动帮你把虚拟机的网络包转发到宿主机的网络栈上。4.2 构建带网络功能的 RIOT 镜像并启动为了能在 QEMU 里测网络吞吐我需要一个带网卡驱动的 RIOT 镜像。以 gnrc_networking 为例在编译时指定目标为 qemu-riscv32make BOARDqemu-riscv32 allRIOT 的 qemu-riscv32 目标会自动挂载 virtio 网卡因此在 QEMU 启动参数里也要加上对应设备。最省事的方法是用 RIOT 自带的 term 命令启动make BOARDqemu-riscv32 termRIOT 的 Makefile 会自动组装 QEMU 参数其中通常会包含类似 -netdev user,idnet0 -device virtio-net-device 的选项这样虚拟出来的网卡就接入到了 SLIRP 网络。启动后你会进入 RIOT 的 shell输入 ifconfig 看有没有拿到 IPv4 地址。SLIRP 默认网段是 10.0.2.0/24RIOT 的 DHCP 客户端如果能正常工作你会看到类似 10.0.2.15 的地址。4.3 宿主机的 UDP 打流脚本由于我没有 sudo没法直接用 iperf3 在 QEMU 的 SLIRP 回环上做双向测试所以我用 Python 写了一个最简单的 UDP 打流脚本。这个脚本只需要系统自带的 Python3不需要额外装任何包。RIOT 那边开一个 UDP 接收端口宿主机这边疯狂发包统计丢包率和吞吐。RIOT 侧先设置静态 IP 并启动 UDP 接收ifconfig 6 set 10.0.2.15/24 udp start 8000然后宿主机侧运行打流脚本import socket import time target_ip 10.0.2.15 target_port 8000 payload_size 1024 total_packets 5000 sock socket.socket(socket.AF_INET, socket.SOCK_DGRAM) sock.settimeout(1) payload bx * payload_size sent 0 received 0 start time.time() for i in range(total_packets): sock.sendto(payload, (target_ip, target_port)) sent 1 try: data, addr sock.recvfrom(2048) received 1 except socket.timeout: pass elapsed time.time() - start throughput_mbps (received * payload_size * 8) / (elapsed * 1_000_000) print(sent:, sent) print(received:, received) print(elapsed:, elapsed) print(throughput_mbps:, round(throughput_mbps, 2))这个脚本没有回显机制所以实际上是 UDP 单向打流统计的是 RIOT 那边能收到多少包。为了准确些你也可以在 RIOT 侧用 udp 命令查看接收计数结合脚本的计算结果互相验证。4.4 28 Mbit/s 的结果解读与合理性分析实测下来我在 QEMU SLIRP 链路上测到的稳定吞吐大约是 28 Mbit/s。对直觉来说这比宿主机千兆网卡动辄几百 Mbit/s 的吞吐看起来寒酸得多但在这种模拟环境下已经是相当正常的结果。影响吞吐的主要有三层开销。第一层是 QEMU 的 CPU 模拟每一条 RISC-V 指令都要被翻译成宿主机指令执行协议栈处理任何数据包都要付一份翻译成本。第二层是 SLIRP 的用户态协议栈转发它本身不是为高性能吞吐设计的更多是为了让虚拟机可以上网。第三层是 RIOT 的 GNRC 协议栈它在嵌入式场景下优先保证的是内存占用和实时性吞吐能力本来就不以追求极限为目标。此外UDP 打流的 payload 大小也有影响。我试过 512 字节和 1024 字节两种包1024 字节测出来的吞吐明显更高因为同等数据量下需要处理的包数量更少。如果改成 1400 字节的包理论上还能再往上涨一点但受 MTU 限制超过 1500 字节后就需要 IP 分片反而会拉低性能。所以 28 Mbit/s 不是硬件极限它对应的是“QEMU 模拟 用户态协议栈 GNRC 协议栈”这组固定成本下的一个合理参考值。如果你确定要做产品级的性能验证最后还是得放到真实板卡上跑。5. 实测中的典型问题与排查速查5.1 启动阶段的问题我在整个复现过程中把能踩的坑基本都踩了一遍整理了一个排查表。现象原因解决办法make 时找不到 perl系统 perl 未安装或 PATH 里 conda 环境未激活conda install -c conda-forge perlnative 启动提示 could not open tap device当前用户无 /dev/net/tun 权限改用 QEMU SLIRP 网络模式QEMU 启动后 ifconfig 看不到 IPSLIRP 网段与配置不一致或 DHCP 未触发手动 ifconfig 设置 10.0.2.15/24UDP 打流丢包严重payload 超过 MTU 导致分片控制包大小在 1200 到 1400 字节吞吐始终上不去QEMU 模拟开销 SLIRP 转发开销调整 payload 大小测多次取平均值5.2 构建系统的那些怪毛病RIOT 的构建系统看似简单但对环境变量很敏感。我在多次编译过程中发现如果你在 make 之前改过 GCC 版本或者 conda 环境里 gcc 版本变了一定要先把 build 目录清掉再重新编make BOARDqemu-riscv32 clean make BOARDqemu-riscv32 all否则很容易出现链接时符号找不到或者 objdump 解析失败的情况。这个和我之前用 CMake 构建项目时的经验很像构建缓存一旦残留后续问题排查起来非常闹心。另外RIOT 2026.07 的构建脚本可能会自动检测宿主机是否安装了 clang然后默认用 clang 编译。但 conda 环境里如果没装 clang它会回退到 gcc。这里有个坑如果回退逻辑没生效你可能会看到 clang: command not found。解决办法是显式指定 CCgcc。如果你更习惯 clang也可以 conda install clang 再编译二选一都能过。5.3 网络测试阶段的注意事项测吞吐时千万不要一看数字就采信最好每组参数跑三次取中位数。因为 QEMU 的调度、SLIRP 的动态缓冲、甚至宿主机上的定时任务都可能导致单次测试波动很大。我测 28 Mbit/s 的时候前一次跑出过 25后一次跑出过 30多跑几次才稳定在中位水平。还有一点就是虚拟机的时钟问题。QEMU 的用户态模式下客户机的时钟并不是严格和宿主机实时同步的RIOT 内部基于 tick 的计时在虚拟环境下会有累积误差。虽然 UDP 打流用的 elapsed 时间是宿主机 Python 脚本算的不受影响但在 RIOT 侧统计吞吐时如果你依赖的是 RIOT 的 shell 打印的时间那就要谨慎一点因为它可能因为虚拟时钟不均导致数据偏差。最稳妥的办法是宿主机侧计时RIOT 侧只负责记录收包数。5.4 我对这套流程的优化建议如果看完整个过程你只想带走一句话那就是没有 root 不代表做不了嵌入式验证关键是选对执行路径。Miniconda 解决工具链native 解决快速验证QEMU SLIRP 解决网络接入。这套组合拳在我之后测试其他 RTOS 时也反复用上了尤其是遇到公司机器权限受限的场合几乎成了我的默认起手式。另外如果你未来的应用必须跑在真实板卡上那编译到 native 和 QEMU 的过程虽然省事但千万别把它当作硬件验证。RIOT 的驱动层、中断延迟、功耗管理这些行为在模拟环境下和真实芯片会有明显差异。建议把模拟环境当作代码逻辑验证和性能粗测的入口等到板卡到手再同步交叉编译验证一遍。6. 一点个人实操总结这次折腾下来我最大的感受是受限环境反而逼你把工具的边界摸得更清楚。以前我拿到一台新机器第一反应永远是 sudo apt update 然后无脑装碰到权限不足就直接放弃。这次从 Miniconda 搭环境到 QEMU 启动 RIOT每一步都在用户态完成反而让我把 RIOT 的构建系统、native 目标原理和 SLIRP 网络模式都重新过了一遍。如果以后你也被困在无 sudo 的机器上跑嵌入式项目记得给 conda 一个机会。它虽然不完美但至少帮你把“没有 root 就什么都干不了”的魔咒解掉了。