操作系统嵌入式【免费下载链接】NodeOSLightweight operating system using Node.js as userspace项目地址https://gitcode.com/gh_mirrors/no/NodeOS点击查看免费下载docs/en/Dependencies.md是 NodeOS 官方维护的依赖清单dependency manifest它把整个 NodeOS 生态拆解为六大主仓库与若干公共包并逐层列出每一层的 npm 依赖树。本文以该文档为骨架结合本仓库内的package.json、构建脚本与文档完整解析这份依赖清单每个仓库负责哪一层构建、其依赖项各自承担什么职责、版本声明遵循何种规律以及这份清单如何在真实构建流程中被落地使用。读完本文你将能够对照依赖清单定位 NodeOS 各构建阶段的模块理解用 npm 组装操作系统的工程思路并具备排查构建链路依赖问题的基本能力。NodeOS 的依赖世界观分层构建 npm 万物NodeOS 的核心哲学在 docs/en/README.md 中被概括为一句话provide just enough to let npm provide the rest——系统只提供最低限度的内核与引导能力其余一切命令、服务、库都交给 npm 生态。这意味着 NodeOS 的依赖不仅仅是普通软件的第三方库清单而是操作系统的每一层都由独立的 GitHub 仓库承载、以 npm 包的形式组装。因此核心开发按层进行参见 README.md 的 Introduction 一节barebones定制 Linux 内核 initramfs启动后直接进入裸 Node.js REPLinitramfs引导期环境负责挂载用户分区并接管启动流程rootfs / bootfs只读根文件系统与引导镜像usersfs多用户环境行为与传统操作系统的用户空间一致。Dependencies.md正是这张分层地图的零件清单——它把每个层对应的仓库、以及每个仓库依赖的 npm 包含版本号完整列出。下图依次展示这三个构建层的内容与叠加关系主仓库全景六大构建仓库的层级职责Dependencies.md的 Main repositories 一节列出了六个主仓库。下表汇总其层级归属与核心职责职责描述依据 README.md、docs/en/building_from_source.md 与各仓库依赖结构综合整理主仓库对应构建层核心职责直接依赖顶层NodeOS元仓库汇总层统筹安装、构建、测试与启动barebones / initramfs / usersfs / bootfs / cross-toolchain 等nodeos-cross-toolchainLayer 1交叉编译工具链async、download-manager、fs-extra、prebuild-install、prebuildnodeos-barebonesLayer 1定制内核 启动到 Node.js REPLcpio2tar、download-manager、minimist、nodeos-nodejs、qemu、supposenodeos-initramfsLayer 2引导期挂载文件系统并接管启动download-manager、mount-filesystems、mount-utils、nodeos-nodejs、usrbinenv、qemu、supposenodeos-rootfsLayer 3只读根文件系统与引导镜像download-manager、genfatfs、qemunodeos-usersfsLayer 3多用户用户空间全家桶bin-man、bin-pwd、davius、dhcpjs、debugfs、forever 等 20 项NodeOS 元仓库依赖的汇聚点元仓库即当前所在仓库并不直接实现内核而是通过 package.json 把各构建层的仓库组装起来dependencies: { nodeos-barebones: ^1.0.0-RC3.1, nodeos-initramfs: NodeOS/nodeos-initramfs, nodeos-usersfs: NodeOS/nodeos-usersfs }, devDependencies: { cpio2tar: ^0.0.5, minimist: ^1.2.0, nodeos-bootfs: NodeOS/nodeos-bootfs, nodeos-cross-toolchain: ^1.0.0-RC3.1, prebuild: piranna/prebuild#prerelease, qemu: ^2.9.0, suppose: jprichardson/node-suppose, tar2ext: ^0.0.2 }值得注意的细节nodeos-barebones与nodeos-cross-toolchain使用npm 语义化版本号^1.0.0-RC3.1RC 候选版而nodeos-initramfs、nodeos-usersfs、nodeos-bootfs使用GitHub 仓库引用NodeOS/nodeos-initramfs即直接跟踪这些仓库的 master 分支、不锁定版本——说明 initramfs 与 usersfs 迭代较快构建时取最新源码元仓库的构建产物由scripts/BigRedButton脚本驱动对MACHINEpc与PLATFORMdisk / img / iso / qemu / docker的多种组合逐一执行npm run build与npm test验证每种镜像组合可正常构建见 scripts/BigRedButton。构建层 1nodeos-cross-toolchain —— 交叉编译工具链nodeos-cross-toolchain ├── async ├── download-manager ├── fs-extra └── prebuild-install / prebuild该仓库用于构建跨平台编译工具链Linux 内核、musl libc 等。依赖结构表明其工作模式download-manager负责下载上游工具链源码压缩包并解压见下文公共包章节fs-extra提供fs的增强 API用于构建目录的复制、清理与写入prebuild-install与prebuild编译产物通过prebuild 预编译机制分发与安装避免每台机器重复编译async用于编排多步并行任务。构建层 1nodeos-barebones —— 裸内核与最小 REPLnodeos-barebones ├── cpio2tar │ ├── cpio-stream │ └── tar-stream ├── download-manager ├── minimist (^1.2.0) ├── nodeos-nodejs ├── qemu └── suppose (^0.6.1)barebones 是 NodeOS 的第一层定制 Linux 内核加最小 initramfs启动后直接进入裸 Node.js REPLREADME.md的 Booting process 一节对此有说明。依赖项分工cpio2tar依赖cpio-stream、tar-stream将内核构建产出的cpio 归档initramfs 的标准格式转换为 tar 格式方便后续层在宿主上处理与重打包minimist^1.2.0命令行参数解析用于处理内核/构建参数nodeos-nodejsNodeOS 专用的 Node.js 运行时预编译二进制见公共包章节qemu以 npm 包形式提供的 QEmu 模拟器用于在构建期/测试期直接启动内核验证suppose^0.6.1Node.js 的 PTY 交互模拟库用于自动化模拟终端输入——被测试脚本用来假装在串口终端上登录并执行 REPL 命令验证构建出的镜像确实能启动到 Node.jsdownload-manager获取内核源码等上游资源。从版本上看barebones 的依赖均锁定主版本区间^1.2.0表示 1.2.0 且 2.0.0保证与 RC3 元仓库的兼容性。构建层 2nodeos-initramfs —— 引导期挂载与接管nodeos-initramfs ├── download-manager ├── nodeos-mount-filesystems │ ├── async (^1.5.2) │ ├── mkdirp (^0.5.1) │ ├── rimraf (^2.5.2) │ └── prompt (*) ├── nodeos-mount-utils │ ├── mkdirp (^0.5.1) │ ├── nodeos-mount │ │ ├── async (^1.5.2) │ │ ├── nan (^2.2.0) │ │ ├── grunt (~0.4.5) / grunt-mocha-test (~0.12.7) │ │ ├── grunt-contrib-watch (~0.6.1) / grunt-node-gyp (~3.0.0) │ │ └── q (~1.4.1) │ ├── posix (^4.0.0) │ └── 测试栈: chai (^3.5.0)、errno-codes (^1.0.2)、istanbul (^0.4.3)、 │ mocha (^2.4.5)、proxyquire (^1.7.4)、rimraf (^2.5.2)、 │ sinon (^1.17.3)、sinon-chai (^2.8.0) ├── nodeos-nodejs ├── usrbinenv │ └── kexec (^2.0.0) ├── qemu └── suppose (^0.6.1)initramfs 层是从裸内核到完整用户空间的过渡层负责挂载用户分区并 exec 真正的 NodeOS 代码README 的 Booting process 一节。其依赖项含义nodeos-mount-filesystems在引导期挂载 devfs / procfs / sysfs / tmpfs 等内核提供的文件系统docs/FileSystem.md 中列出了/dev、/proc、/sys、/tmp的标准挂载位置mkdirp创建挂载点、rimraf清理、prompt*表示不锁定版本、按需交互提示nodeos-mount-utils挂载工具集合核心是nodeos-mount——一个基于nan^2.2.0编写的Native 模块C/C 绑定封装底层mount系统调用其开发依赖揭示了原生模块的经典工程栈gruntgrunt-node-gyp构建、grunt-mocha-test跑测试、grunt-contrib-watch监听、q做 Promise 编排而posix^4.0.0提供 POSIX 系统调用封装。nodeos-mount-utils 自身携带完整测试栈mocha chai sinon sinon-chai proxyquire istanbul 覆盖率说明挂载逻辑被当作核心模块严谨对待usrbinenv依赖kexec提供/usr/bin/env的实现。本仓库 scripts/postinstall 的注释解释了其特殊性npm 会把所有包的二进制软链进node_modules/.bin而 usrbinenv 的env可执行文件 shebang 是#!/bin/node仅在 NodeOS 上有效会干扰宿主构建过程因此 postinstall 脚本专门删除该软链。kexec则用于在引导期直接跳转到最终 init 进程替换当前进程映像。构建层 3nodeos-rootfs —— 只读根文件系统镜像nodeos-rootfs ├── download-manager ├── genfatfs │ ├── prebuild-install (^1.1.0) │ └── prebuild (^4.2.2) └── qemurootfs 负责生成只读根文件系统与引导镜像ISO 等。genfatfs是一个FAT 文件系统镜像生成器同样采用 prebuild 预编译分发prebuild-install下载预编译二进制、prebuild负责在缺失时本地编译。qemu用于构建完成后直接启动镜像做冒烟验证。结合 docs/en/building_from_source.md 中 rootfs dependencies:genisoimage libuuid:i386 的系统级依赖可以推断该层产物包括 ISO 引导镜像。构建层 3nodeos-usersfs —— 多用户空间全家桶usersfs 是依赖清单中最大的一支承载 NodeOS 的全部用户态功能。Dependencies.md原文完整列出如下nodeos-usersfs ├── bin-man ├── bin-pwd ├── davius │ ├── finalhandler (^0.4.1) │ ├── fs-extra (^0.26.2) │ ├── minimist (^1.2.0) │ ├── oneshoot │ │ ├── async (^1.5.0) │ │ ├── escape-html (^1.0.3) │ │ ├── serve-static (^1.10.0) │ │ └── ws (^0.8.0) │ ├── recv │ ├── rimraf (^2.4.4) │ └── serve-static │ ├── parseurl (~1.3.0) │ ├── send │ └── 测试栈: istanbul (0.4.1)、mocha (2.3.4)、supertest (1.1.0) ├── dhcpjs (^0.5.0) ├── debugfs │ └── async (^1.5.0) ├── forever ├── forever-monitor ├── genext2fs │ ├── prebuild-install (1.0.2) │ └── prebuild (^4.2.2) ├── ifconfig │ ├── src-sockios │ ├── src-ifaddrs │ │ └── nan (^2.0.9) │ └── src-errno │ └── nan (^2.0.9) ├── ip │ └── src-sockios ├── loadtest (^1.4.3) ├── logon │ ├── colors (^1.1.2) │ ├── kexec (^2.0.2) │ ├── posix (^4.0.0) │ ├── prompt (^1.0.0) │ └── 测试栈: mocha (^2.4.5)、mocha-eslint (^2.0.2) ├── node-bin-getty │ ├── src-unistd │ │ └── nan (^2.0.9) │ └── src-termios │ └── nan (^2.0.9) ├── node-wget │ ├── request (~2.27.0) │ └── 工程栈: license-md (~0.2.5)、grunt (~0.4.1)、grunt-bump (~0.0.11)、 │ grunt-license (~0.1.4)、mocha (~1.12.0)、should (~1.2.2) ├── nodeos-nodejs ├── nodeos-reverse-proxy │ ├── basic-auth (^1.0.4) │ ├── concat-stream (^1.5.1) │ ├── finalhandler (^0.5.0) │ ├── http-proxy (^1.14.0) │ ├── kexec (^2.0.2) │ ├── posix (^4.0.2) │ ├── uuid (^2.0.2) │ └── 测试栈: mocha (^2.5.3)、supertest (^1.2.0) ├── npm (^3.9.6) ├── nsh │ ├── array-flatten (^2.1.0) │ ├── async (^2.0.1) │ ├── decode-prompt (^0.0.2) │ ├── glob (~7.0.5) │ ├── lib-pathcomplete │ │ ├── glob (~7.0.5) │ │ └── pathchop (0.0.0) │ ├── lib-pathsearch │ ├── mkdirp (~0.5.1) │ ├── mkfifo (^0.1.5) │ ├── npm-path (^2.0.2) │ ├── shell-parse (^0.0.2) │ ├── to-string-stream (^0.1.0) │ ├── uuid (^2.0.2) │ ├── concat-stream (^1.5.1) │ └── 测试栈: easy-coveralls、mocha (^2.5.3)、string-to-stream (^1.1.0) ├── ntp-client (^0.5.3) ├── performance (^1.1.0) ├── pstree │ ├── archy (^1.0.0) │ ├── async (^1.5.2) │ └── scanf (^0.7.2) ├── slap (^0.1.60) └── qemu按功能把这些包归为几组基础用户命令bin-manman 手册页、bin-pwdpwd、node-wget基于request的 wget 式下载器、npm^3.9.6——NodeOS 把 npm 本体直接作为用户空间包管理工具docs/FileSystem.md提到用户目录的bin与lib/node_modules由npkg/npm 管理。登录与会话logon登录进程依赖kexec切换进程、posix获取用户信息、prompt交互输入、colors输出着色、node-bin-getty终端 getty通过src-unistd与src-termios两个基于nan的原生绑定操作终端。docs/en/README.md描述的默认登录用户名/密码均为nodeos正是由这组模块驱动的。Shell 与脚本环境nshNodeOS Shell完整命令文档见 docs/en/nsh/Commands.md其依赖几乎覆盖了一个 Shell 的全部能力shell-parse解析命令行、globlib-pathcomplete/lib-pathsearch做路径补全与搜索、mkdirp/mkfifo管理文件系统、npm-path定位 npm、to-string-stream/concat-stream处理流、decode-prompt解码终端提示符。nsh 的存在印证了 usersfs 层以 Node.js 组件组装传统 Shell 体验的设计。网络与系统服务dhcpjs^0.5.0DHCP 客户端、ifconfig/ip网络接口配置依赖src-sockios、src-ifaddrs等nan原生绑定、nodeos-reverse-proxyHTTP 反向代理基于http-proxybasic-auth鉴权、ntp-client^0.5.3时间同步、pstree通过scanf解析/proc输出进程树archy渲染树形图、performance^1.1.0性能监控、slap^0.1.60终端文本编辑器、loadtest^1.4.3负载测试工具、foreverforever-monitor进程守护与监控。文件服务与调试daviusHTTP 文件服务器内置oneshoot服务器——依赖serve-static提供静态文件、ws提供 WebSocket、escape-html转义输出serve-static自身基于parseurl与send、debugfs调试文件系统、genext2fsext2 镜像生成器prebuild 预编译分发。共享底座nodeos-nodejsNode.js 运行时与qemu模拟器再次出现说明 usersfs 构建时同样需要编译运行与验证环境。从版本策略看usersfs 大量使用^主版本约束少数使用~如node-wget的request ~2.27.0表示仅允许补丁级更新glob ~7.0.5同理既有较激进的主版本跟随也有保守的补丁锁定体现了用户态组件自由迭代、核心组件谨慎升级的分层管理思路。公共包串起所有分层的共享底座Dependencies.md的 Common packages 一节列出了跨层共享的五个公共包它们是各构建层反复引用的基建。download-manager —— 各层构建的下载管道download-manager ├── async (^2.0.1) ├── bzip2-maybe │ ├── is-bzip2 (^1.0.0) │ ├── peek-stream (^1.1.1) │ ├── pumpify (^1.3.5) │ ├── through2 (^2.0.1) │ ├── unbzip2-stream (^1.0.9) │ └── 测试栈: concat-stream (^1.5.1)、easy-coveralls、 │ standard (^8.0.0-beta.5)、tape (^4.6.0) ├── diff ├── download-checksum │ ├── inherits (^2.0.1) │ └── openpgp (^2.3.2) ├── force-array (^3.1.0) ├── got (^6.3.0) ├── gunzip-maybe (^1.3.1) ├── multi-progress (^2.0.0) ├── pump (^1.0.1) ├── rimraf (^2.5.4) ├── strip-dirs (^2.0.0) ├── tar-fs (^1.13.0) └── 测试栈: easy-coveralls、mocha (^3.0.2)、nock (^8.0.0)、tmp (0.0.28)download-manager 是 barebones / cross-toolchain / initramfs / rootfs 共用的下载-解压-校验管道got负责 HTTP 下载gunzip-maybe/bzip2-maybe自动识别 gzip/bzip2 解压tar-fs解包 tarstrip-dirs剥离目录层级download-checksum通过openpgp做签名校验multi-progress展示多任务进度条pump/pumpify管理流force-array归一化输入。其测试栈mocha nock tmp说明下载逻辑通过 mock HTTP 响应做了充分的单元验证。nodeos-nodejs —— 内嵌 Node.js 运行时nodeos-nodejs ├── prebuild-install (1.0.2) ├── buho │ ├── concat-stream (^1.5.1) │ ├── github-basic │ ├── github-from-package (0.0.0) │ ├── github-url-to-object (^2.2.3) │ ├── minimist (^1.2.0) │ └── 测试栈: easy-coveralls、mocha (^2.5.3)、nock (^8.0.0) ├── prebuild (^4.2.2) └── publishnodeos-nodejs 是打进每个构建层的 Node.js 运行时docs/FileSystem.md指出/bin存放最新 node 可执行文件。其依赖模式表明buho从GitHub Release拉取预编译 Node.js 二进制github-from-package从 package.json 提取仓库信息、github-url-to-object构造 release URL配合prebuild-install/prebuild完成预编译分发publish负责发布流程。qemu —— 预编译模拟器qemu ├── prebuild-install (1.0.2) └── prebuild (^4.2.2)qemu 以 npm 包形态提供 QEmu 模拟器的预编译二进制被多个构建层用于构建即验证。它在当前仓库中的落地证据非常直接元仓库的 lib/index.js 会根据out/latest软链解析 cpu_family/machine/platform拼出qemu-system-cpu_family命令行-m 256M、-net user端口转发等并在检测到 KVM 支持时追加-enable-kvmscripts/start 再以该命令行 spawn 进程。这正好对应 Dependencies.md 中 qemu 在 barebones / initramfs / rootfs / usersfs 四层的反复出现——每层构建完都要真机启动验证。src-sockios —— 原生 socket 绑定src-sockios └── nan (^2.0.9)src-sockios 是基于nan的 socket ioctlsockios原生绑定模块被 usersfs 的ifconfig与ip共用负责在用户空间直接操作网络接口配置。easy-coveralls —— 覆盖率上报easy-coveralls ├── coveralls (^2.11.11) ├── fs-extra (^0.30.0) ├── jscoverage └── mocha-lcov-reporter (^1.2.0)easy-coveralls 是测试链路的公共件用jscoverage生成覆盖率、mocha-lcov-reporter输出 LCOV 格式、coveralls上报到 CI。它在 nsh、download-manager、buho、nodeos-nodejs 等多个仓库的测试栈中反复出现说明 NodeOS 生态对各模块的 CI 覆盖有统一约定。依赖清单背后的工程模式通读整份依赖清单可以提炼出 NodeOS 依赖管理的几个显著模式均为从清单结构可以观察到的实现事实原生模块一律 prebuild 化nodeos-mount、genfatfs、genext2fs、qemu、nodeos-nodejs、src-*系列几乎都成对出现prebuildprebuild-install预编译二进制按平台分发避免构建期交叉编译瓶颈原生绑定统一基于nan^2.xsrc-sockios、src-ifaddrs、src-errno、src-unistd、src-termios、nodeos-mount全部依赖nan保证跨 Node.js 版本 ABI 稳定测试栈高度统一mocha 为测试运行器istanbul 覆盖率chai/sinon/sinon-chai/proxyquire 用于断言与 mocknock 用于 HTTP mocksupertest 用于 HTTP 集成测试easy-coveralls 上报覆盖率下载-构建-启动验证闭环download-manager取料→ prebuild编译→ qemu suppose启动镜像并模拟终端交互验证几乎出现在每一个构建层仓库中semver 策略分层核心层多用^主版本内兼容个别组件用~补丁级锁定prompt (*)与 GitHub 仓库引用则表示不锁版本、跟随最新。与仓库源码的落地对照以上依赖清单并非纸面文档其运行逻辑在当前仓库中有多处源码佐证package.json 中的scripts定义了build、postbuild、postinstall、start、test、unbuild、BigRedButton等生命周期入口它们是依赖清单中各仓库被组装进构建流程的挂载点scripts/BigRedButton 遍历MACHINEpc×PLATFORMdisk/img/iso/qemu/docker×BITS32/64的组合执行构建与测试印证了每层都要可启动验证的设计lib/index.js 与 scripts/start 完整呈现了 qemu 依赖在运行期的调用链从out/cpu_family/machine/platform读取产物按 platform 选择-hdadisk、-cdrom-hdaiso、--kernel--initrd-driveqemu 直启内核initramfs等启动方式scripts/postinstall 处理 usrbinenv 的env软链与宿主构建环境的冲突是依赖间运行时环境差异的典型修补点docs/FileSystem.md 描述了 usersfs 层的目录规约$HOME/bin可执行命令、$HOME/lib/node_modulesnpkg 安装的模块、$HOME/log、$HOME/etc、$HOME/var、$HOME/tmp——这正是 nsh、npm、logon 等 usersfs 依赖包运行时的数据落点。延伸阅读与上手路径想要把依赖清单跑起来参考 docs/en/building_from_source.md其中给出了 Debian/Ubuntu 与 Arch Linux 的系统级依赖安装cross compiler、barebones、rootfs、initramfs、userfs、qemu 各组对应不同的apt-get/pacman包以及npm install、npm start的完整流程想要理解依赖最终形成的文件系统布局阅读 docs/FileSystem.md系统目录/bin、/root、/home、/dev、/proc、/sys、/tmp与用户目录$HOME的规约想要从哲学层面把握为什么依赖如此设计阅读 docs/en/README.md 与 README.md 的分层与启动流程介绍想要深入某个 usersfs 组件nsh的命令手册位于 docs/en/nsh/Commands.md。总而言之docs/en/Dependencies.md是理解 NodeOS 工程形态的最佳入口它不是一张普通的依赖清单而是用 npm 组装操作系统这一理念的可执行蓝图——六个主仓库对应六个构建阶段五个公共包构成共享底座每一层都遵循下载 → 预编译 → 模拟器启动验证的同一套工程节律。赞分享操作系统嵌入式【免费下载链接】NodeOSLightweight operating system using Node.js as userspace项目地址https://gitcode.com/gh_mirrors/no/NodeOS点击查看免费下载相关推荐MyViewOfLinuxSystems项目详解用户空间程序的内核依赖MyViewOfLinuxSystems项目详解用户空间程序的内核依赖 你是否曾好奇当你双击桌面上的应用图标时这个简单动作背后隐藏着怎样复杂的系统协作为ReScript Compiler与npm生态集成包管理与依赖解析ReScript Compiler与npm生态集成包管理与依赖解析 项目依赖配置基础 ReScript Compiler通过 package.json 与np编译器编程语言开发工具npm CLI 依赖全景图解读 DEPENDENCIES.md 与依赖分层架构npm CLI 依赖全景图解读 DEPENDENCIES.md 与依赖分层架构 npm the package manager for JavaScript开发工具包管理器CLI上一篇StyleGAN多分辨率训练从4x4到1024x1024的渐进式生成指南下一篇AssetRipper实操手册如何把一个Unity游戏文件拆成可编辑的资源创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考