操作系统嵌入式【免费下载链接】NodeOSLightweight operating system using Node.js as userspace项目地址https://gitcode.com/gh_mirrors/no/NodeOS点击查看免费下载NodeOS 是一个以 Node.js 作为用户态、用 npm 作为包管理器的轻量级操作系统详见 README.md。在这样一个没有全局服务、没有全局模块、没有全局命令的系统里文件系统如何组织直接决定了包的安装方式、服务的运行方式和用户的隔离方式。本文以仓库设计文档 docs/FileSystem.md 为核心骨架结合 docs/root.md、docs/init.md、docs/asgard.md 等关联文档系统讲解 NodeOS 的目录设计原则、系统目录与用户目录的边界、内核挂载点以及 root 用户如何借助这套布局完成系统启动。读完本文你将掌握 NodeOS 文件系统的完整心智模型并能据此理解npkg安装包、服务配置与日志、以及 init/asgard 之间的目录协作关系。从整体架构看文件系统的位置NodeOS 的开发按分层进行各层分别对应文件系统的一个组成部分详见 README.md 的 Introduction 部分barebones定制 Linux 内核 initramfs启动后进入 Node.js REPLinitramfs初始化内存环境负责挂载用户分区并启动系统usersfs多用户环境行为与传统操作系统一致。下图doc/NodeOS Layer 2 - initramfs.png展示了 initramfs 层在 barebones 基础软件栈之上mount-filesystems负责挂载文件系统usrbinenv负责环境准备这一层正是文件系统布局的搬运工——它决定了后续挂载到哪个根、哪些用户目录会被识别。NodeOS Layer 2 initramfs 架构mount-filesystems 负责挂载文件系统而最终承载用户与应用的则是 usersfs 层doc/NodeOS Layer 3 - usersfs.png其中可以看到root与普通用户目录的划分root下运行着 PalmTree服务启动器、bin-getty、logon 等系统组件用户侧则是 npm、nsh 等工具——这正是本文要详解的目录布局落地形态。NodeOS Layer 3 usersfs 架构展示 root 与普通用户目录的划分系统目录为兼容 libc 而保留的私有目录NodeOS 基础文件系统的布局遵循一个核心原则传统 Linux 的系统级目录被视为私有目录仅为了兼容当前使用的 libc 而保留。它们在启动后由系统自身管理用户不应直接写入。/bin -- contains latest node executable /lib /usr /etc也就是说/bin中放置的是最新版 Node.js 可执行文件而非一堆系统命令——NodeOS 不需要/bin/ls、/bin/cp这类传统二进制命令是各用户自己安装的见下文用户目录/lib、/usr、/etc的存在更多是满足 glibc/musl 等 C 运行库对标准路径的隐式依赖让现有 Node.js 二进制和原生模块能够正常工作所有用户可编辑的内容都应该放到用户目录中而不是这些系统目录。设计文档 docs/product.md 将 FileSystem 定位为技术与产品的混合体目录的挪动是为了技术上更好地组织系统但又不希望文件系统对用户显得陌生——这解释了为何保留标准 Linux 路径形态、同时把可写空间全部收敛到用户目录。用户目录root 与普通用户的分界所有用户可编辑的内容位于用户目录中root 用户的 home 目录使用标准位置/root非 root 用户则位于/home下/root -- root user /home -- non-root usersroot 用户是特殊的它负责启动整个系统。普通用户目录则彼此隔离每位用户在自己的$HOME内拥有完整的软件环境。这一设计在 docs/root.md 中有更详细的展开我们将在root 目录与系统启动一节继续说明。内核提供的文件系统挂载在常规位置其他由内核提供的文件系统被挂载在它们的常规位置用户可以直接访问但数据性质各不相同/dev -- devfs /proc -- procfs /sys -- sysfs /tmp -- tmpfs/devdevfs设备文件对应系统的各种硬件设备节点/procprocfs进程信息/proc/cpuinfo等内核与进程状态接口/syssysfs内核对象与驱动的 sysfs 视图/tmptmpfs内存文件系统重启后内容即失。值得留意的是尽管/tmp是内核提供的 tmpfsNodeOS 依然在用户目录中为每个用户保留了tmp/临时数据这是因为系统性的临时空间与用户任务的临时空间在生命周期与权限语义上并不相同。用户目录详解每个 $HOME 就是一个小型根文件系统NodeOS 最颠覆性的设计是没有全局的服务、模块或命令。曾经属于系统级的目录如etc、var现在都变成用户局部的。每个用户的$HOME结构如下$HOME/ bin/ -- executable commands ls, cp, mv lib/ node_modules/ -- modules installed by npkg log/ -- logs from init jobs etc/ -- configuration files var/ -- persistent data tmp/ -- ephemeral data各目录职责细化如下目录职责说明bin可执行命令包含ls、cp、mv等命令在npkg install时创建命令链接lib模块库存放处lib/node_modules存放由npkg安装的模块log日志存放 init 任务服务和作业产生的输出日志etc配置存放服务和作业的本地配置值var持久数据存放服务和作业的持久化数据tmp临时数据存放服务和作业的临时数据原文档特别强调这些目录的约定是被npkg命令假定并使用的。也就是说npkg install会把可执行文件软链到$HOME/bin、把模块放进$HOME/lib/node_modules服务管理器会把日志写入$HOME/log、配置放在$HOME/etc、持久数据存在$HOME/var。理解这一约定是理解 NodeOS每个用户一套环境的钥匙——不同用户安装同一包互不干扰因为各自的bin/lib/etc互不相同。root 目录与系统启动init 与 asgardroot 用户与普通用户一样遵循$HOME布局但额外承担启动职责。其最小目录集合为docs/root.md/root/ bin/ init -- boots the system asgard -- service manager started by init lib/ -- installed node_modules for init/asgard log/ -- log files from init and other root services var/ -- persistent data for root services即 root 的bin/中安装着init负责启动系统与asgard由 init 启动的服务管理器。root 目录至少需要上述内容通常还会包含其他对启动系统有帮助的模块。init 进程与 PID 1内核加载完成后会把控制权交给一个通常被称为init process的进程。该进程拥有 PID 1必须启动系统的其余部分如果 init 未能启动系统内核要么 panic要么机器什么也不做。传统 Linux 上 init 位于/sbin/init若启动时不指定内核会自动在该位置查找。但也可以在启动时通过向内核传递INITpath参数指定任意进程作为 PID 1。NodeOS 正是利用了这一点NodeOS 在/sbin/init处没有进程它的 init 只是安装到/root/bin/的一个可执行文件init 本身是一个 Node.js 模块其package.json中包含bin键任何带bin键的 Node 模块都可以充当 NodeOS 的 init只是项目提供一个够用且最小的 init 模块。init 的双重职责docs/init.md 描述了 init 的设计它会是一个超简单的进程只做两件事周期性地收割死掉的子进程reap dead children启动根服务管理器 asgard。为什么需要收割僵尸进程Linux 的机制是当父进程死亡后其子进程会被收养为 PID 1 的子进程。当这些子进程退出时它们的 PID 号与退出状态会记录在内核进程表中作为父进程的 init 需要周期性地调用wait或waitpid来清空进程表。已退出但尚未被清空的进程被称为zombie僵尸进程。由于 init 会收养大量子进程如果它们退出后无人清收系统就会僵尸泛滥因此 init 必须扮演死神grim reaper的角色。服务管理器 asgard 与 PalmTreeinit 就绪后会把控制权移交给服务管理器。设计文档 docs/asgard.md 描述的 asgard 是任务运行型服务提供两个底层抽象task任务一个必须运行的真实进程queue队列任务的有序列表。其行为特征包括任务一旦加入队列即被运行同一队列内的任务顺序执行不同队列并行执行空队列只是等待新任务对队列操作的支持有限。需要注意的是asgard 页面已明确标注Deprecated弃用NodeOS 现采用PalmTree作为服务启动器见 docs/en/Service-Starter-(PalmTree).md.md) 与 docs/services.md。PalmTree 使用/etc下的palmtree.json文件它是一个 JSON 编码的对象数组每个对象最少包含要执行的命令可选name与args[ { command: plexdl, name: PlexDL, args: [beta-gui] } ]启动时 PalmTree 会按此配置运行命令增加/移除开机服务只需编辑该 JSON 数组也可以在 Node.js 中require该文件、修改后再序列化写回实现编程式管理。这与本文件系统文档呼应etc/用户局部配置目录正是palmtree.json这类配置的落点。与源码实现的印证分层构建与镜像挂载这套文件系统设计在仓库构建层面得到了印证。根目录 package.json 将构建拆分为三个核心依赖nodeos-barebones内核与基础层nodeos-initramfs初始化内存文件系统含挂载逻辑nodeos-usersfs用户态文件系统这与 README 中的三层结构一一对应。此外lib/index.js 中的prepareCommandLine展示了各平台启动时如何挂载这些文件系统镜像img平台-hda bootfs.img-hdb usersfs.img双磁盘启动文件系统 用户文件系统iso平台-cdrom bootfs.iso-hda usersfs.imgqemu平台--kernel kernel--initrd initramfs.cpio.gzusersfs.img作为根盘追加root/dev/sda、ipdhcp等内核参数。从源码结构看bootfs启动镜像含内核与 initramfs与usersfs用户文件系统含各用户$HOME始终被分开管理用户数据与系统核心互不混杂正是本文所述系统目录私有化、用户目录承载一切可写内容原则的落地体现。总结NodeOS 将传统 Linux 系统目录/bin、/lib、/usr、/etc降级为仅供 libc 兼容的私有区域所有用户可编辑内容进入用户目录root 用户在标准/root非 root 用户在/home每位用户的$HOME内含bin/lib/log/etc/var/tmp完整目录集并被npkg等工具默认使用内核文件系统devfs、procfs、sysfs、tmpfs仍挂载在常规位置/root/bin中的init作为 PID 1 收割僵尸进程并启动服务管理器最终由 PalmTree或早期设计中的 asgard拉起全部用户服务构建层面通过 barebones / initramfs / usersfs 三层依赖与 bootfs、usersfs 双镜像保证系统核心与用户文件系统物理分离。这套无全局、纯用户局部的文件系统设计是 NodeOS让 npm 提供其余一切理念的基石没有中心化的包目录没有系统级守护进程每个用户在自己的$HOME里拥有完整、隔离、可随时重建的软件环境。赞分享操作系统嵌入式【免费下载链接】NodeOSLightweight operating system using Node.js as userspace项目地址https://gitcode.com/gh_mirrors/no/NodeOS点击查看免费下载相关推荐免费解锁WeMod专业版Wand-Enhancer完整使用指南免费解锁WeMod专业版Wand Enhancer完整使用指南 还在为WeMod的高级功能付费而烦恼吗Wand Enhancer是一款专为WeMod设计的开桌面应用前端NodeOS 的 root 用户与 init 引导体系从 /root 目录到 PID 1 的启动链路解析NodeOS 的 root 用户与 init 引导体系从 /root 目录到 PID 1 的启动链路解析 本篇技术指南围绕 NodeOS 仓库的 docs/r操作系统嵌入式FontForge 文件体系全解用户配置目录、崩溃恢复与系统共享资源FontForge 文件体系全解用户配置目录、崩溃恢复与系统共享资源 导读 FontForge 是一款免费开源的字体编辑器它在用户主目录与系统共享目录中维护桌面应用图形学创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
