Compare commits
2 Commits
8a2011f2d0
...
35a6980c50
| Author | SHA1 | Date | |
|---|---|---|---|
|
|
35a6980c50 | ||
|
|
00e8d4811c |
59
.devcontainer/Dockerfile
Normal file
59
.devcontainer/Dockerfile
Normal file
@@ -0,0 +1,59 @@
|
||||
# meta-unit-core/.devcontainer/Dockerfile
|
||||
|
||||
# 使用一个包含 Rust 工具链的官方镜像作为基础
|
||||
# 推荐使用 rustlang/rust:latest-bullseye 或其他稳定版本
|
||||
# 也可以选择 slim 镜像以减小体积,但可能需要手动安装更多基础工具
|
||||
FROM rust:bullseye
|
||||
|
||||
# 设置工作目录
|
||||
WORKDIR /app
|
||||
|
||||
# 1. 安装系统依赖 (如果需要)
|
||||
# 例如,如果你的 Rust 项目依赖于某些 C 库 (如 OpenSSL, SQLite), 则在此安装
|
||||
# 对于 meta-unit-core 这样纯 Rust + WASM 的项目,初期可能不多
|
||||
# RUN apt-get update && apt-get install -y \
|
||||
# pkg-config \
|
||||
# libssl-dev \
|
||||
# build-essential \
|
||||
# # ... 其他你项目可能需要的系统依赖
|
||||
# && rm -rf /var/lib/apt/lists/*
|
||||
|
||||
# 2. 安装 Rustup 组件
|
||||
# rust-analyzer 是 IDE 智能感知的核心,clippy 用于 Linting,rustfmt 用于格式化
|
||||
# 这些工具应该在容器内,而不是在宿主机上运行,以保证一致性
|
||||
RUN rustup component add rust-analyzer clippy rustfmt
|
||||
|
||||
# 3. 添加 WASM 编译目标
|
||||
# 这是 Yuan (Meta Unit) 的核心目标
|
||||
RUN rustup target add wasm32-unknown-unknown
|
||||
|
||||
# 4. 安装 Protobuf 相关工具
|
||||
# 编译 .proto 文件为 Rust 代码需要这些工具
|
||||
# prost-build 是 Rust 的 Protobuf 代码生成库,我们通常在 Cargo.toml 中作为 build-dependency
|
||||
# 这里我们指的是安装 protoc 编译器本身
|
||||
# 方法一:通过 apt-get 安装 (如果源里有的话)
|
||||
# RUN apt-get update && apt-get install -y protobuf-compiler
|
||||
|
||||
# 方法二:下载并安装 protoc (更通用且版本可控)
|
||||
ARG PROTOC_VERSION="3.20.1"
|
||||
# 可以根据 meta-unit-proto 的版本来调整
|
||||
RUN apt-get update && apt-get install -y curl unzip \
|
||||
&& curl -LO https://github.com/protocolbuffers/protobuf/releases/download/v${PROTOC_VERSION}/protoc-${PROTOC_VERSION}-linux-x86_64.zip \
|
||||
&& unzip protoc-${PROTOC_VERSION}-linux-x86_64.zip -d /usr/local \
|
||||
&& rm protoc-${PROTOC_VERSION}-linux-x86_64.zip \
|
||||
&& apt-get clean && rm -rf /var/lib/apt/lists/*
|
||||
|
||||
# 5. 安装其他可选的 Rust 工具 (如果需要)
|
||||
# 例如,wasm-pack 是用于 Rust 到 WASM 编译的工具,在开发 web-sys 或 node 环境下的 WASM 模块时很有用
|
||||
# 对于 meta-unit-core,可能不是必需的,因为我们直接编译为 wasm32-unknown-unknown
|
||||
# RUN cargo install wasm-pack
|
||||
|
||||
# 将 Cargo 的 bin 目录添加到 PATH (通常 rustlang/rust 基础镜像已完成)
|
||||
# ENV PATH="/usr/local/cargo/bin:${PATH}"
|
||||
|
||||
# 设置默认用户,防止以 root 身份运行 (可选,但推荐用于安全)
|
||||
# RUN useradd -ms /bin/bash developer
|
||||
# USER developer
|
||||
|
||||
# 暴露端口 (如果你的项目需要监听端口,例如在集成测试中启动一个模拟服务)
|
||||
# EXPOSE 8080
|
||||
55
.devcontainer/devcontainer.json
Normal file
55
.devcontainer/devcontainer.json
Normal file
@@ -0,0 +1,55 @@
|
||||
// meta-unit-core/.devcontainer/devcontainer.json
|
||||
{
|
||||
// 显示在 IDE 中的 Dev Container 名称
|
||||
"name": "Meta Unit Core Development Environment",
|
||||
|
||||
// 指向你的 docker-compose.yml 文件
|
||||
// 因为 devcontainer.json 和 docker-compose.yml 都在 .devcontainer 目录下,所以直接引用文件名
|
||||
"dockerComposeFile": "docker-compose.yml",
|
||||
|
||||
// 指定 docker-compose.yml 中哪个服务是你的主要开发容器。
|
||||
// 在我们之前的规划中,这个服务的名称是 'meta-unit-dev'
|
||||
"service": "meta-unit-dev",
|
||||
|
||||
// 指定容器内部你的项目代码的挂载路径。
|
||||
// 这与 docker-compose.yml 中 volumes: - .:/app 的容器端路径一致。
|
||||
"workspaceFolder": "/app",
|
||||
|
||||
// 容器创建后,打开工作区之前或之后运行的命令。
|
||||
// 适合进行首次的依赖更新或检查,确保环境就绪。
|
||||
"postCreateCommand": "cargo update && cargo check",
|
||||
|
||||
// 可选:端口转发配置。如果你的项目内部有服务需要暴露到宿主机,在这里添加。
|
||||
// 例如,如果你在测试中启动一个模拟服务,或者未来有本地调试接口。
|
||||
// "forwardPorts": [8080],
|
||||
|
||||
// 可选:如果你在 Dockerfile 中创建了非 root 用户 (例如 'developer'),可以在此指定。
|
||||
// "remoteUser": "developer",
|
||||
|
||||
// 可选:针对特定 IDE 的定制。
|
||||
// 虽然这里主要是为 VS Code 设计,但包含一些通用设置对未来切换或参考也有帮助。
|
||||
// JetBrains IDEs 会忽略 VS Code 相关的设置,但会利用 dockerComposeFile 和 service 等核心配置。
|
||||
"customizations": {
|
||||
"vscode": {
|
||||
"settings": {
|
||||
// Rust-specific settings for VS Code
|
||||
"rust-analyzer.checkOnSave.command": "clippy", // 建议使用 clippy 进行保存时检查
|
||||
"editor.formatOnSave": true, // 保存时自动格式化
|
||||
"rust-analyzer.diagnostics.enable": true,
|
||||
"rust-analyzer.linkedProjects": [ // 告诉 rust-analyzer 你的 Cargo.toml 在哪里
|
||||
"./Cargo.toml"
|
||||
],
|
||||
"rust-analyzer.cargo.buildScripts.enable": true, // 如果 build.rs 很重要
|
||||
"rust-analyzer.completion.callable.snippets": "fill_arguments" // 填充函数参数
|
||||
},
|
||||
"extensions": [
|
||||
// VS Code 推荐的 Rust 扩展
|
||||
"rust-lang.rust-analyzer",
|
||||
"vadimcn.vscode-lldb", // Rust 调试器
|
||||
"tamasfe.even-better-toml", // TOML 文件增强
|
||||
"serayuzgur.crates", // Cargo.toml 依赖管理辅助
|
||||
"swellaby.vscode-rust-test-explorer" // Rust 测试探索
|
||||
]
|
||||
}
|
||||
}
|
||||
}
|
||||
44
.devcontainer/docker-compose.yml
Normal file
44
.devcontainer/docker-compose.yml
Normal file
@@ -0,0 +1,44 @@
|
||||
services:
|
||||
# 定义你的开发容器服务
|
||||
meta-unit-dev:
|
||||
# 使用上一步我们定义的 Dockerfile 构建镜像
|
||||
# 如果 Dockerfile 在 .devcontainer/Dockerfile,则 build context 指向 .devcontainer
|
||||
build:
|
||||
context: . # build context 指向当前项目根目录,以便 Dockerfile 可以访问整个项目
|
||||
dockerfile: Dockerfile # 指定 Dockerfile 的路径
|
||||
# args: # 如果 Dockerfile 有 ARG 参数,可以在这里传递
|
||||
# PROTOC_VERSION: "3.20.1"
|
||||
|
||||
# 容器名称,方便识别和管理
|
||||
container_name: meta-unit-dev-env
|
||||
|
||||
# 将本地项目代码挂载到容器的 /app 目录
|
||||
# 这样你在本地修改代码,容器内会实时同步
|
||||
volumes:
|
||||
- .:/app # 将当前目录 (meta-unit-core 项目根目录) 挂载到容器的 /app
|
||||
|
||||
# 端口映射 (如果你的项目有服务需要从容器内部暴露到宿主机)
|
||||
# 例如,未来集成测试中,如果模拟的 Avatar Host 需要监听某个端口
|
||||
# - "8080:8080" # 宿主机端口:容器端口
|
||||
|
||||
# 默认命令 (可选)
|
||||
# 通常 JetBrains IDE 会覆盖这个命令来启动其后端服务
|
||||
# command: /bin/bash # 启动一个 bash shell,方便手动进入容器调试
|
||||
|
||||
# 特权模式 (可选,通常不建议,但在一些极端低层级开发或调试时可能需要)
|
||||
# privileged: true
|
||||
|
||||
# 环境变量 (可选)
|
||||
environment:
|
||||
# RUST_LOG: debug # 设置 Rust 日志级别,方便调试
|
||||
# CARGO_HOME: /usr/local/cargo # 确保 Cargo 路径正确(通常镜像已处理)
|
||||
# RUSTUP_HOME: /usr/local/rustup # 确保 Rustup 路径正确(通常镜像已处理)
|
||||
TZ: Asia/Singapore # 设置时区,与你的开发环境一致
|
||||
|
||||
# 保持容器运行,即使没有进程在前端运行 (对于开发容器很重要)
|
||||
stdin_open: true # docker run -i
|
||||
tty: true # docker run -t
|
||||
|
||||
# 额外的参数,例如 CPU/内存限制,或其他 Docker 特性
|
||||
# cpuset: "0-1"
|
||||
# mem_limit: "2g"
|
||||
0
.gitea/workflows/ci.yml
Normal file
0
.gitea/workflows/ci.yml
Normal file
16
.gitignore
vendored
16
.gitignore
vendored
@@ -6,7 +6,7 @@ target/
|
||||
|
||||
# Remove Cargo.lock from gitignore if creating an executable, leave it for libraries
|
||||
# More information here https://doc.rust-lang.org/cargo/guide/cargo-toml-vs-cargo-lock.html
|
||||
Cargo.lock
|
||||
#Cargo.lock
|
||||
|
||||
# These are backup files generated by rustfmt
|
||||
**/*.rs.bk
|
||||
@@ -19,4 +19,16 @@ Cargo.lock
|
||||
# be found at https://github.com/github/gitignore/blob/main/Global/JetBrains.gitignore
|
||||
# and can be added to the global gitignore or merged into this file. For a more nuclear
|
||||
# option (not recommended) you can uncomment the following to ignore the entire idea folder.
|
||||
#.idea/
|
||||
.idea/
|
||||
|
||||
|
||||
# Added by cargo
|
||||
|
||||
/target
|
||||
|
||||
|
||||
# Added by cargo
|
||||
#
|
||||
# already existing elements were commented out
|
||||
|
||||
#/target
|
||||
|
||||
70
CODE_OF_CONDUCT-CN.md
Normal file
70
CODE_OF_CONDUCT-CN.md
Normal file
@@ -0,0 +1,70 @@
|
||||
# 贡献者契约行为准则
|
||||
|
||||
## 我们的承诺
|
||||
|
||||
作为社区成员、贡献者和领导者,我们承诺:让每个人都能在我们的社区中获得免受骚扰的体验,无论其年龄、体型、可见或不可见的残疾、种族、性特征、性别认同和表达、经验水平、教育程度、社会经济地位、国籍、个人外貌、种族、宗教信仰或性取向。
|
||||
|
||||
我们承诺以有助于开放、欢迎、多元、包容和健康的社区的方式行事和互动。
|
||||
|
||||
## 我们的标准
|
||||
|
||||
有助于为社区创造积极环境的行为示例包括:
|
||||
|
||||
* 对他人的同情和友善
|
||||
* 尊重不同的意见、观点和经验
|
||||
* 给出并欣然接受建设性的反馈
|
||||
* 对因我们的错误而受到影响的人承担责任并道歉,并从中吸取教训
|
||||
* 专注于不仅对我们个人而言是最好的,而且对整个社区也是最好的
|
||||
|
||||
不可接受的行为示例包括:
|
||||
|
||||
* 使用性化语言或图像,以及任何形式的性关注或性挑逗
|
||||
* 挑衅、侮辱性或贬损性评论,以及人身或政治攻击
|
||||
* 公开或私下骚扰
|
||||
* 未经他人明确许可,发布他人的私人信息,例如实际地址或电子邮件地址
|
||||
* 在专业环境中,其他可合理地被认为不当的行为
|
||||
|
||||
## 执行责任
|
||||
|
||||
社区领导者负责明确和执行我们可接受的行为标准,并对他们认为不适当、威胁性、冒犯性或有害的任何行为采取适当和公平的纠正措施。
|
||||
|
||||
社区领导者有权也有责任删除、编辑或拒绝不符合本行为准则的评论、提交、代码、维基编辑、工单和其他贡献,并将在适当时候传达审查决定的理由。
|
||||
|
||||
## 范围
|
||||
|
||||
本行为准则适用于所有社区空间,也适用于个人在公共场合正式代表社区时。代表我们社区的例子包括使用官方电子邮件地址、通过官方社交媒体账户发布内容,或作为指定代表参加线上或线下活动。
|
||||
|
||||
## 执行指南
|
||||
|
||||
社区领导者将遵循以下社区影响指南来确定任何被他们认为违反本行为准则的行为的后果:
|
||||
|
||||
### 1. 纠正
|
||||
|
||||
**社区影响**:使用不当语言或其他被认为不专业或不受社区欢迎的行为。
|
||||
|
||||
**后果**:社区领导者发出私人书面警告,明确违反的性质并解释为何该行为不当。可能会要求公开道歉。
|
||||
|
||||
### 2. 警告
|
||||
|
||||
**社区影响**:通过单一事件或一系列行为造成的违规。
|
||||
|
||||
**后果**:附带后续行为后果的警告。此警告没有时间限制,但要求个人改变行为。在指定时间内,禁止与相关人员进行任何互动,包括未经请求地与执行行为准则的人员进行互动。这包括避免在社区空间以及社交媒体等外部渠道进行互动。违反这些条款可能导致暂时或永久禁言。
|
||||
|
||||
### 3. 暂时禁言
|
||||
|
||||
**社区影响**:严重违反社区标准,包括持续的不当行为。
|
||||
|
||||
**后果**:在指定时间内,禁止与社区进行任何形式的互动或公开交流。在此期间,禁止与相关人员进行任何公开或私下互动,包括未经请求地与执行行为准则的人员进行互动。违反这些条款可能导致永久禁言。
|
||||
|
||||
### 4. 永久禁言
|
||||
|
||||
**社区影响**:表现出持续违反社区标准的模式,包括持续的不当行为、对个人的骚扰,或对某类人的攻击或贬低。
|
||||
|
||||
**后果**:永久禁止与社区进行任何形式的互动或公开交流。
|
||||
|
||||
## 归属
|
||||
|
||||
本行为准则改编自 [Contributor Covenant][homepage] 2.1 版,可在 [https://www.contributor-covenant.org/version/2/1/code_of_conduct.html][v2.1] 获取。
|
||||
|
||||
[homepage]: https://www.contributor-covenant.org
|
||||
[v2.1]: https://www.contributor-covenant.org/version/2/1/code_of_conduct.html
|
||||
70
CODE_OF_CONDUCT.md
Normal file
70
CODE_OF_CONDUCT.md
Normal file
@@ -0,0 +1,70 @@
|
||||
# Contributor Covenant Code of Conduct
|
||||
|
||||
## Our Pledge
|
||||
|
||||
We as members, contributors, and leaders pledge to make participation in our community a harassment-free experience for everyone, regardless of age, body size, visible or invisible disability, ethnicity, sex characteristics, gender identity and expression, level of experience, education, socio-economic status, nationality, personal appearance, race, religion, or sexual identity and orientation.
|
||||
|
||||
We pledge to act and interact in ways that contribute to an open, welcoming, diverse, inclusive, and healthy community.
|
||||
|
||||
## Our Standards
|
||||
|
||||
Examples of behavior that contributes to a positive environment for our community include:
|
||||
|
||||
* Demonstrating empathy and kindness toward other people
|
||||
* Being respectful of differing opinions, viewpoints, and experiences
|
||||
* Giving and gracefully accepting constructive feedback
|
||||
* Accepting responsibility and apologizing to those affected by our mistakes, and learning from the experience
|
||||
* Focusing on what is best not just for us as individuals, but for the overall community
|
||||
|
||||
Examples of unacceptable behavior include:
|
||||
|
||||
* The use of sexualized language or imagery, and sexual attention or advances of any kind
|
||||
* Trolling, insulting or derogatory comments, and personal or political attacks
|
||||
* Public or private harassment
|
||||
* Publishing others' private information, such as a physical or email address, without their explicit permission
|
||||
* Other conduct which could reasonably be considered inappropriate in a professional setting
|
||||
|
||||
## Enforcement Responsibilities
|
||||
|
||||
Community leaders are responsible for clarifying and enforcing our standards of acceptable behavior and will take appropriate and fair corrective action in response to any behavior that they deem inappropriate, threatening, offensive, or harmful.
|
||||
|
||||
Community leaders have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, and will communicate reasons for moderation decisions when appropriate.
|
||||
|
||||
## Scope
|
||||
|
||||
This Code of Conduct applies within all community spaces, and also applies when an individual is officially representing the community in public spaces. Examples of representing our community include using an official e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event.
|
||||
|
||||
## Enforcement Guidelines
|
||||
|
||||
Community leaders will follow these Community Impact Guidelines in determining the consequences for any action they deem in violation of this Code of Conduct:
|
||||
|
||||
### 1. Correction
|
||||
|
||||
**Community Impact**: Use of inappropriate language or other behavior deemed unprofessional or unwelcome in the community.
|
||||
|
||||
**Consequence**: A private, written warning from community leaders, providing clarity around the nature of the violation and an explanation of why the behavior was inappropriate. A public apology may be requested.
|
||||
|
||||
### 2. Warning
|
||||
|
||||
**Community Impact**: A violation through a single incident or series of actions.
|
||||
|
||||
**Consequence**: A warning with consequences for continued behavior. There is no time limit to this warning, but the individual is expected to change behavior. No interaction with the people involved, including unsolicited interaction with those enforcing the Code of Conduct, for a specified period of time. This includes avoiding interaction in community spaces as well as external channels like social media. Violating these terms may lead to a temporary or permanent ban.
|
||||
|
||||
### 3. Temporary Ban
|
||||
|
||||
**Community Impact**: A serious violation of community standards, including sustained inappropriate behavior.
|
||||
|
||||
**Consequence**: A temporary ban from any sort of interaction or public communication with the community for a specified period of time. No public or private interaction with the involved people, including unsolicited interaction with those enforcing the Code of Conduct, is allowed during this period. Violating these terms may lead to a permanent ban.
|
||||
|
||||
### 4. Permanent Ban
|
||||
|
||||
**Community Impact**: Demonstrating a pattern of violation of community standards, including sustained inappropriate behavior, harassment of an individual, or aggression toward or disparagement of classes of individuals.
|
||||
|
||||
**Consequence**: A permanent ban from any sort of interaction or public communication with the community.
|
||||
|
||||
## Attribution
|
||||
|
||||
This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 2.1, available at [https://www.contributor-covenant.org/version/2/1/code_of_conduct.html][v2.1].
|
||||
|
||||
[homepage]: https://www.contributor-covenant.org
|
||||
[v2.1]: https://www.contributor-covenant.org/version/2/1/code_of_conduct.html
|
||||
100
CONTRIBUTING-CN.md
Normal file
100
CONTRIBUTING-CN.md
Normal file
@@ -0,0 +1,100 @@
|
||||
# 贡献 meta-unit-core
|
||||
|
||||
[English](CONTRIBUTING.md)
|
||||
|
||||
我们热烈欢迎你为 `meta-unit-core`(大道 OS 的基础微内核)做出贡献。你的努力将帮助塑造赛博生命计算的未来!
|
||||
|
||||
---
|
||||
|
||||
## 1. 贡献前须知
|
||||
|
||||
在开始之前,请花一点时间阅读以下指南:
|
||||
|
||||
* **行为准则:** 请阅读并遵守我们的 [行为准则](CODE_OF_CONDUCT.md)(即将推出)。我们致力于营造一个开放、包容的环境。
|
||||
* **开发指南:** 按照我们的 [开发指南](GUIDE.md) 设置你的开发环境。这能确保你拥有所有必要的工具和一致的设置。
|
||||
* **理解愿景:** 熟悉 [大道操作系统项目](https://nest.doylee.cn/dao-os/Dao-OS-Project) 的整体愿景,以及 `meta-unit-core` 在其中扮演的角色。
|
||||
|
||||
---
|
||||
|
||||
## 2. 如何贡献
|
||||
|
||||
我们遵循**基于主干开发 (Trunk-Based Development - TBD)** 的工作流,以确保快速迭代和持续集成。
|
||||
|
||||
### 报告 Bug
|
||||
|
||||
如果你发现了 Bug,请在我们的 [Gitea 工单追踪器](https://nest.doylee.cn/dao-os/meta-unit-core/issues) 上提交一个工单。
|
||||
|
||||
* **先搜索:** 检查现有工单,看 Bug 是否已被报告。
|
||||
* **清晰描述:** 提供 Bug 的清晰简洁描述。
|
||||
* **重现步骤:** 包含重现 Bug 的详细步骤。
|
||||
* **预期行为与实际行为:** 描述你期望发生的情况和实际发生的情况。
|
||||
* **环境:** 提供你的环境详细信息(操作系统、Rust 版本、Docker 版本等)。
|
||||
|
||||
### 提出增强或新功能建议
|
||||
|
||||
我们热爱新想法!如果你有建议:
|
||||
|
||||
* **提交工单:** 在 [工单追踪器](https://nest.doylee.cn/dao-os/meta-unit-core/issues) 上详细描述你的想法。
|
||||
* **理由:** 解释为什么这个增强或功能对项目有价值。
|
||||
* **潜在设计:** 如果你对如何实现有想法,请一并包含。
|
||||
|
||||
### 你的首次代码贡献
|
||||
|
||||
对于你的首次贡献,可以考虑在我们的 [工单追踪器](https://nest.doylee.cn/dao-os/meta-unit-core/issues) 上查找标记为 `good first issue` 或 `help wanted` 的工单。
|
||||
|
||||
### 代码贡献工作流 (TBD)
|
||||
|
||||
1. **拉取最新主干代码:** 始终从 `main` 分支拉取最新的更改到你的本地机器。
|
||||
```bash
|
||||
git pull origin main
|
||||
```
|
||||
2. **创建短生命周期的特性分支:** 为了你的本地开发,创建一个新分支。这个分支应该专注于一个单一的、小的、原子性的更改,并尽快合并回 `main`。
|
||||
```bash
|
||||
git checkout -b feature/my-new-awesome-thing
|
||||
# 或者用于 Bug 修复:
|
||||
git checkout -b bugfix/fix-that-issue
|
||||
```
|
||||
*命名约定:* 优先使用 `feature/`、`bugfix/`、`docs/`、`refactor/` 前缀。
|
||||
3. **开发与测试:**
|
||||
* **测试驱动开发 (TDD):** 我们鼓励在编写代码*之前*编写测试,以确保代码的正确性和可维护性。
|
||||
* 进行小而逻辑性的提交,并附上清晰的提交信息。
|
||||
* 确保所有现有测试通过(`cargo test`)。
|
||||
* 为你的更改添加新测试。
|
||||
4. **格式化和代码检查:** 在提交之前,请确保你的代码符合我们的风格指南。
|
||||
```bash
|
||||
cargo fmt --all # 应用格式更改
|
||||
cargo clippy --all-targets --all-features -- -D warnings # 运行 linter,将所有警告视为错误
|
||||
```
|
||||
5. **推送你的分支:**
|
||||
```bash
|
||||
git push origin your-branch-name
|
||||
```
|
||||
6. **创建拉取请求 (PR):**
|
||||
* 访问我们的 [Gitea 仓库](https://nest.doylee.cn/dao-os/meta-unit-core),并从你的分支向 `main` 分支创建一个新的拉取请求。
|
||||
* **PR 标题:** 使用清晰、简洁的标题总结你的更改。
|
||||
* **PR 描述:** 提供你的更改的详细描述,为什么进行这些更改,任何相关的工单号,以及如何测试它们(如果适用)。
|
||||
* **CI 检查:** 确保所有持续集成 (CI) 检查通过。
|
||||
7. **快速审查与合并:** 你的 PR 将被快速审查。一旦通过批准且 CI 通过,它将被合并到 `main`。我们目标是小而频繁的合并。
|
||||
8. **大型功能使用特性开关:** 对于跨越多个 PR 或开发周期的大型或未完成的功能,直接提交到 `main`,但用 [特性开关 (feature flags)](https://docs.rs/feature-flags/latest/feature_flags/) 包裹新代码。这确保 `main` 分支始终保持稳定和可发布状态。
|
||||
|
||||
---
|
||||
|
||||
## 3. 代码风格和约定
|
||||
|
||||
* **Rust 格式化:** 我们使用 `rustfmt` 来强制执行代码风格。提交前务必运行 `cargo fmt`。
|
||||
* **Clippy:** 我们使用 `clippy` 进行代码检查。所有 `clippy` 警告都必须解决(`cargo clippy --all-targets --all-features -- -D warnings`)。
|
||||
* **提交信息:** 遵循清晰简洁的提交信息约定(例如,[Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/))。
|
||||
* *示例:* `feat: 添加新的 IPC 机制` 或 `fix: 解决任务调度器中的竞争条件`
|
||||
* **文档:** 所有公共函数、结构体、枚举和模块都应该有清晰的 Rustdoc 注释 (`///`)。强烈鼓励提供示例。
|
||||
|
||||
---
|
||||
|
||||
## 4. 社区与交流
|
||||
|
||||
* **工单追踪器:** [https://nest.doylee.cn/dao-os/meta-unit-core/issues](https://nest.doylee.cn/dao-os/meta-unit-core/issues) (用于 Bug、功能和讨论)
|
||||
* **聊天/论坛:** (如果建立了 Discord、Matrix 或论坛,可以在此处添加链接)
|
||||
* **拉取请求:** 用于提交代码更改。
|
||||
|
||||
感谢你对 `meta-unit-core` 贡献的兴趣!我们期待你的贡献。
|
||||
|
||||
---
|
||||
100
CONTRIBUTING.md
Normal file
100
CONTRIBUTING.md
Normal file
@@ -0,0 +1,100 @@
|
||||
# Contributing to meta-unit-core
|
||||
|
||||
[中文](CONTRIBUTING-CN.md)
|
||||
|
||||
We warmly welcome your contributions to `meta-unit-core`, the foundational microkernel for the Dao OS. Your efforts help shape the future of CyberLife computation!
|
||||
|
||||
---
|
||||
|
||||
## 1. Before You Contribute
|
||||
|
||||
Before you start, please take a moment to review these guidelines:
|
||||
|
||||
* **Code of Conduct:** Please read and adhere to our [Code of Conduct](CODE_OF_CONDUCT.md) (coming soon). We are committed to fostering an open and welcoming environment.
|
||||
* **Development Guide:** Set up your development environment by following our [Development Guide](GUIDE.md). This ensures you have all the necessary tools and a consistent setup.
|
||||
* **Understand the Vision:** Familiarize yourself with the overall vision of the [Dao Operating System Project](https://nest.doylee.cn/dao-os/Dao-OS-Project) and how `meta-unit-core` fits into it.
|
||||
|
||||
---
|
||||
|
||||
## 2. How to Contribute
|
||||
|
||||
We follow a **Trunk-Based Development (TBD)** workflow to ensure rapid iteration and continuous integration.
|
||||
|
||||
### Reporting Bugs
|
||||
|
||||
If you find a bug, please open an issue on our [Gitea Issue Tracker](https://nest.doylee.cn/dao-os/meta-unit-core/issues).
|
||||
|
||||
* **Search First:** Check existing issues to see if the bug has already been reported.
|
||||
* **Clear Description:** Provide a clear and concise description of the bug.
|
||||
* **Steps to Reproduce:** Include detailed steps to reproduce the bug.
|
||||
* **Expected vs. Actual Behavior:** Describe what you expected to happen and what actually happened.
|
||||
* **Environment:** Provide details about your environment (OS, Rust version, Docker version, etc.).
|
||||
|
||||
### Suggesting Enhancements or New Features
|
||||
|
||||
We love new ideas! If you have a suggestion:
|
||||
|
||||
* **Open an Issue:** Describe your idea in detail on the [Issue Tracker](https://nest.doylee.cn/dao-os/meta-unit-core/issues).
|
||||
* **Justification:** Explain why this enhancement or feature would be valuable to the project.
|
||||
* **Potential Design:** If you have thoughts on how it could be implemented, include them.
|
||||
|
||||
### Your First Code Contribution
|
||||
|
||||
For your first contribution, consider looking for issues marked with `good first issue` or `help wanted` on our [Issue Tracker](https://nest.doylee.cn/dao-os/meta-unit-core/issues).
|
||||
|
||||
### Code Contribution Workflow (TBD)
|
||||
|
||||
1. **Pull Latest Main:** Always start by fetching and pulling the very latest changes from the `main` branch to your local machine.
|
||||
```bash
|
||||
git pull origin main
|
||||
```
|
||||
2. **Create a Short-Lived Feature Branch:** For your local development, create a new branch. This branch should focus on a single, small, atomic change and be merged back into `main` quickly.
|
||||
```bash
|
||||
git checkout -b feature/my-new-awesome-thing
|
||||
# Or for a bug fix:
|
||||
git checkout -b bugfix/fix-that-issue
|
||||
```
|
||||
*Naming Convention:* Prefer `feature/`, `bugfix/`, `docs/`, `refactor/` prefixes.
|
||||
3. **Develop & Test:**
|
||||
* **Test-Driven Development (TDD):** We encourage writing tests *before* writing the code to ensure correctness and maintainability.
|
||||
* Make small, logical commits with clear commit messages.
|
||||
* Ensure all existing tests pass (`cargo test`).
|
||||
* Add new tests for your changes.
|
||||
4. **Format and Lint:** Before committing, ensure your code adheres to our style guidelines.
|
||||
```bash
|
||||
cargo fmt --all # Apply formatting changes
|
||||
cargo clippy --all-targets --all-features -- -D warnings # Run linter, treating all warnings as errors
|
||||
```
|
||||
5. **Push Your Branch:**
|
||||
```bash
|
||||
git push origin your-branch-name
|
||||
```
|
||||
6. **Create a Pull Request (PR):**
|
||||
* Go to our [Gitea repository](https://nest.doylee.cn/dao-os/meta-unit-core) and create a new Pull Request from your branch to the `main` branch.
|
||||
* **PR Title:** Use a clear, concise title summarizing your changes.
|
||||
* **PR Description:** Provide a detailed description of your changes, why they were made, any relevant issue numbers, and how to test them (if applicable).
|
||||
* **CI Checks:** Ensure all Continuous Integration (CI) checks pass.
|
||||
7. **Fast Review & Merge:** Your PR will be reviewed quickly. Once approved and CI passes, it will be merged into `main`. We aim for small, frequent merges.
|
||||
8. **Use Feature Flags for Large Features:** For larger or incomplete features that span multiple PRs or development cycles, commit directly to `main` but wrap the new code with [feature flags](https://docs.rs/feature-flags/latest/feature_flags/). This ensures the `main` branch always remains stable and releasable.
|
||||
|
||||
---
|
||||
|
||||
## 3. Code Style and Conventions
|
||||
|
||||
* **Rust Format:** We use `rustfmt` to enforce code style. Always run `cargo fmt` before committing.
|
||||
* **Clippy:** We use `clippy` for linting. All `clippy` warnings must be resolved (`cargo clippy --all-targets --all-features -- -D warnings`).
|
||||
* **Commit Messages:** Follow a clear and concise commit message convention (e.g., [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/)).
|
||||
* *Example:* `feat: Add new IPC mechanism` or `fix: Resolve race condition in task scheduler`
|
||||
* **Documentation:** All public functions, structs, enums, and modules should have clear Rustdoc comments (`///`). Examples are highly encouraged.
|
||||
|
||||
---
|
||||
|
||||
## 4. Community and Communication
|
||||
|
||||
* **Issue Tracker:** [https://nest.doylee.cn/dao-os/meta-unit-core/issues](https://nest.doylee.cn/dao-os/meta-unit-core/issues) (for bugs, features, and discussions)
|
||||
* **Chat/Forum:** (Consider adding a Discord, Matrix, or forum link here if you set one up)
|
||||
* **Pull Requests:** Used for submitting code changes.
|
||||
|
||||
Thank you for your interest in contributing to `meta-unit-core`! We look forward to your contributions.
|
||||
|
||||
---
|
||||
7
Cargo.lock
generated
Normal file
7
Cargo.lock
generated
Normal file
@@ -0,0 +1,7 @@
|
||||
# This file is automatically @generated by Cargo.
|
||||
# It is not intended for manual editing.
|
||||
version = 4
|
||||
|
||||
[[package]]
|
||||
name = "meta-unit-core"
|
||||
version = "0.1.0"
|
||||
6
Cargo.toml
Normal file
6
Cargo.toml
Normal file
@@ -0,0 +1,6 @@
|
||||
[package]
|
||||
name = "meta-unit-core"
|
||||
version = "0.1.0"
|
||||
edition = "2024"
|
||||
|
||||
[dependencies]
|
||||
123
GUIDE-CN.md
Normal file
123
GUIDE-CN.md
Normal file
@@ -0,0 +1,123 @@
|
||||
# meta-unit-core 开发指南
|
||||
|
||||
[English](GUIDE.md)
|
||||
|
||||
本指南将引导你设置 `meta-unit-core` 的开发环境,我们推荐使用 Dev Containers 以确保环境的一致性,并涵盖必要的 Rust 工具链。
|
||||
|
||||
---
|
||||
|
||||
## 1. 前提条件
|
||||
|
||||
在开始之前,请确保你的系统已安装以下软件:
|
||||
|
||||
* **Docker Desktop (或 Docker Engine):** 运行 Dev Containers 所必需。
|
||||
* [下载 Docker Desktop](https://www.docker.com/products/docker-desktop)
|
||||
* **JetBrains Gateway (用于 RustRover):** 推荐用于远程开发的 IDE。
|
||||
* [下载 JetBrains Gateway](https://www.jetbrains.com/remote-development/gateway/)
|
||||
* 或者,你也可以使用安装了 Dev Containers 扩展的 VS Code。
|
||||
|
||||
---
|
||||
|
||||
## 2. 设置开发环境(推荐:Dev Containers)
|
||||
|
||||
我们使用 Dev Containers 为所有贡献者提供一致且隔离的开发环境。
|
||||
|
||||
1. **克隆仓库:**
|
||||
```bash
|
||||
git clone https://nest.doylee.cn/dao-os/meta-unit-core.git
|
||||
cd meta-unit-core
|
||||
```
|
||||
|
||||
2. **使用 JetBrains Gateway 打开:**
|
||||
* 启动 **JetBrains Gateway**。
|
||||
* 选择 **"Dev Containers"** 选项卡。
|
||||
* 点击 **"Connect to Dev Container"** 或类似选项。
|
||||
* 导航并选择 `meta-unit-core` 项目目录(你克隆仓库的位置)。JetBrains Gateway 将自动检测到 `.devcontainer/devcontainer.json` 文件。
|
||||
* 按照提示连接。Gateway 将构建容器(如果是首次连接),并打开连接到远程环境的 RustRover。
|
||||
|
||||
3. **容器内的初始设置:**
|
||||
首次连接时,`.devcontainer/devcontainer.json` 中定义的 `postCreateCommand` (`cargo update && cargo check`) 将自动运行。这将获取所有 Rust 依赖项并执行初步的健全性检查。
|
||||
|
||||
如果你不使用 Dev Containers,你需要手动确保以下工具已安装:
|
||||
* **Rust 工具链:** 从 [rustup.rs](https://rustup.rs/) 安装 `rustup`。
|
||||
* **WASM 目标:** 添加 WASM 目标:`rustup target add wasm32-unknown-unknown`
|
||||
* **Cargo 子命令:** 安装有用的子命令,如 `cargo-watch`、`cargo-edit`、`cargo-tarpaulin`(用于覆盖率)、`mdbook`(用于文档)。
|
||||
* **Protobuf 工具:** 如果你直接处理 `.proto` 文件(而非通过 `meta-unit-proto` 项目的构建过程),则需要 `protoc` 编译器和 `protoc-gen-prost`(用于 Rust 代码生成)。
|
||||
|
||||
---
|
||||
|
||||
## 3. 构建项目
|
||||
|
||||
进入 Dev Container 后,你可以构建项目:
|
||||
|
||||
```bash
|
||||
cargo build
|
||||
```
|
||||
|
||||
以发布模式(优化性能)构建:
|
||||
|
||||
```bash
|
||||
cargo build --release
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 4. 运行测试
|
||||
|
||||
我们优先采用测试驱动开发 (TDD)。运行所有测试:
|
||||
|
||||
```bash
|
||||
cargo test
|
||||
```
|
||||
|
||||
运行特定测试:
|
||||
|
||||
```bash
|
||||
cargo test <测试名称或正则表达式>
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 5. 格式化和代码检查
|
||||
|
||||
在提交代码之前,请确保它符合我们的代码风格并通过了代码检查:
|
||||
|
||||
```bash
|
||||
cargo fmt --all -- --check # 检查格式而不应用更改
|
||||
cargo fmt --all # 应用格式更改
|
||||
|
||||
cargo clippy --all-targets --all-features -- -D warnings # 运行 linter,将所有警告视为错误
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 6. 贡献工作流(基于主干开发)
|
||||
|
||||
我们遵循**基于主干开发 (Trunk-Based Development - TBD)** 的工作流:
|
||||
|
||||
1. **拉取最新主干代码:** 始终从 `main` 分支拉取最新更改。
|
||||
```bash
|
||||
git pull origin main
|
||||
```
|
||||
2. **创建短生命周期的特性分支:** 为了你的本地开发,创建一个新分支。这个分支应该很快合并回 `main`。
|
||||
```bash
|
||||
git checkout -b my-feature-branch
|
||||
```
|
||||
3. **开发与测试 (TDD):** 进行小而原子性的提交。先编写测试,然后编写代码使其通过。
|
||||
4. **推送并创建拉取请求 (PR):** 推送你的分支并在 Gitea 上向 `main` 分支发起拉取请求。
|
||||
```bash
|
||||
git push origin my-feature-branch
|
||||
```
|
||||
5. **快速审查与合并:** 你的 PR 将被快速审查。一旦通过批准且 CI 通过,它将被合并到 `main`。
|
||||
6. **使用特性开关:** 对于较大或未完成的特性,直接提交到 `main`,但用 [特性开关 (feature flags)](https://docs.rs/feature-flags/latest/feature_flags/) 包裹新代码。这确保 `main` 始终保持可发布状态。
|
||||
|
||||
---
|
||||
|
||||
## 7. 故障排除
|
||||
|
||||
* **容器构建失败:** 检查 `meta-unit-core/.devcontainer/Dockerfile` 和 `docker-compose.yml` 是否有语法错误。确保 Docker Desktop 正在运行并有足够的资源。
|
||||
* **"No such file or directory" for `Dockerfile`:** 仔细检查 `Dockerfile`、`docker-compose.yml` 和 `devcontainer.json` 是否都在 `meta-unit-core/.devcontainer/` 目录下,并确保 `docker-compose.yml` 的 `build` 上下文设置正确(`context: .` 和 `dockerfile: Dockerfile`)。
|
||||
* **容器内权限错误:** 确保容器内部运行的用户(如果不是 root)对挂载的 `/app` 目录具有适当的权限。你可能需要调整宿主机上该目录的所有权/权限。
|
||||
* **`cargo build` 慢:** 确保 Docker Desktop 分配了足够的 CPU 和内存。可以考虑使用 `sccache` 加速构建。
|
||||
|
||||
---
|
||||
123
GUIDE.md
Normal file
123
GUIDE.md
Normal file
@@ -0,0 +1,123 @@
|
||||
# Development Guide for meta-unit-core
|
||||
|
||||
[中文](GUIDE-CN.md)
|
||||
|
||||
This guide will walk you through setting up your development environment for `meta-unit-core` using Dev Containers (recommended for consistency) and the necessary Rust toolchains.
|
||||
|
||||
---
|
||||
|
||||
## 1. Prerequisites
|
||||
|
||||
Before you begin, ensure you have the following installed on your system:
|
||||
|
||||
* **Docker Desktop (or Docker Engine):** Required for running Dev Containers.
|
||||
* [Download Docker Desktop](https://www.docker.com/products/docker-desktop)
|
||||
* **JetBrains Gateway (for RustRover):** The recommended IDE for remote development.
|
||||
* [Download JetBrains Gateway](https://www.jetbrains.com/remote-development/gateway/)
|
||||
* Alternatively, you can use VS Code with the Dev Containers extension.
|
||||
|
||||
---
|
||||
|
||||
## 2. Setting Up the Development Environment (Recommended: Dev Containers)
|
||||
|
||||
We use Dev Containers to provide a consistent and isolated development environment for all contributors.
|
||||
|
||||
1. **Clone the Repository:**
|
||||
```bash
|
||||
git clone https://nest.doylee.cn/dao-os/meta-unit-core.git
|
||||
cd meta-unit-core
|
||||
```
|
||||
|
||||
2. **Open with JetBrains Gateway:**
|
||||
* Launch **JetBrains Gateway**.
|
||||
* Select the **"Dev Containers"** tab.
|
||||
* Click **"Connect to Dev Container"** or a similar option.
|
||||
* Navigate to and select the `meta-unit-core` project directory (where you cloned the repository). JetBrains Gateway will automatically detect the `.devcontainer/devcontainer.json` file.
|
||||
* Follow the prompts to connect. Gateway will build the container (if it's the first time) and open RustRover connected to the remote environment.
|
||||
|
||||
3. **Initial Setup within the Container:**
|
||||
Upon first connection, the `postCreateCommand` defined in `.devcontainer/devcontainer.json` (`cargo update && cargo check`) will automatically run. This fetches all Rust dependencies and performs an initial sanity check.
|
||||
|
||||
If you're not using Dev Containers, you'll need to manually ensure you have:
|
||||
* **Rust Toolchain:** Install `rustup` from [rustup.rs](https://rustup.rs/).
|
||||
* **WASM Target:** Add the WASM target: `rustup target add wasm32-unknown-unknown`
|
||||
* **Cargo Subcommands:** Install useful subcommands like `cargo-watch`, `cargo-edit`, `cargo-tarpaulin` (for coverage), `mdbook` (for docs).
|
||||
* **Protobuf Tools:** `protoc` compiler and `protoc-gen-prost` (for Rust code generation) if you're working directly with `.proto` files outside the `meta-unit-proto` project's build process.
|
||||
|
||||
---
|
||||
|
||||
## 3. Building the Project
|
||||
|
||||
Once inside the Dev Container, you can build the project:
|
||||
|
||||
```bash
|
||||
cargo build
|
||||
```
|
||||
|
||||
To build in release mode (optimized for performance):
|
||||
|
||||
```bash
|
||||
cargo build --release
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 4. Running Tests
|
||||
|
||||
We prioritize Test-Driven Development (TDD). To run all tests:
|
||||
|
||||
```bash
|
||||
cargo test
|
||||
```
|
||||
|
||||
To run a specific test:
|
||||
|
||||
```bash
|
||||
cargo test <test_name_or_regex>
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 5. Formatting and Linting
|
||||
|
||||
Before submitting your code, please ensure it adheres to our code style and passes lint checks:
|
||||
|
||||
```bash
|
||||
cargo fmt --all -- --check # Check formatting without applying changes
|
||||
cargo fmt --all # Apply formatting changes
|
||||
|
||||
cargo clippy --all-targets --all-features -- -D warnings # Run linter with all warnings as errors
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 6. Contributing Workflow (Trunk-Based Development)
|
||||
|
||||
We follow a **Trunk-Based Development (TBD)** workflow:
|
||||
|
||||
1. **Pull Latest Main:** Always start by pulling the latest changes from the `main` branch.
|
||||
```bash
|
||||
git pull origin main
|
||||
```
|
||||
2. **Create a Short-Lived Feature Branch:** For your local development, create a new branch. This branch should be merged back into `main` quickly.
|
||||
```bash
|
||||
git checkout -b my-feature-branch
|
||||
```
|
||||
3. **Develop & Test (TDD):** Make small, atomic commits. Write tests first, then code to pass them.
|
||||
4. **Push and Create Pull Request (PR):** Push your branch and open a Pull Request against the `main` branch on Gitea.
|
||||
```bash
|
||||
git push origin my-feature-branch
|
||||
```
|
||||
5. **Fast Review & Merge:** Your PR will be reviewed quickly. Once approved and CI passes, it will be merged into `main`.
|
||||
6. **Use Feature Flags:** For larger or incomplete features, commit directly to `main` but wrap the new code with [feature flags](https://docs.rs/feature-flags/latest/feature_flags/). This ensures `main` always remains releasable.
|
||||
|
||||
---
|
||||
|
||||
## 7. Troubleshooting
|
||||
|
||||
* **Container fails to build:** Check `meta-unit-core/.devcontainer/Dockerfile` and `docker-compose.yml` for syntax errors. Ensure Docker Desktop is running and has enough resources.
|
||||
* **"No such file or directory" for `Dockerfile`:** Double-check that `Dockerfile`, `docker-compose.yml`, and `devcontainer.json` are all in the `meta-unit-core/.devcontainer/` directory, and that `docker-compose.yml`'s `build` context is set correctly (`context: .` and `dockerfile: Dockerfile`).
|
||||
* **Permissions errors in container:** Ensure the user running inside the container (if not root) has appropriate permissions to the mounted `/app` directory. You might need to adjust ownership/permissions on your host system.
|
||||
* **Slow `cargo build`:** Ensure Docker Desktop has sufficient CPU and memory allocated. Leverage `sccache` for faster builds.
|
||||
|
||||
---
|
||||
46
README-CN.md
Normal file
46
README-CN.md
Normal file
@@ -0,0 +1,46 @@
|
||||
# meta-unit-core
|
||||
|
||||
[English](README.md)
|
||||
|
||||
**大道操作系统的基础微内核。**
|
||||
|
||||
---
|
||||
|
||||
## 概述
|
||||
|
||||
`meta-unit-core` 是 [大道操作系统项目](https://nest.doylee.cn/dao-os) 的核心——一个为新兴赛博生命时代构建的新颖、去中心化且支持多语言的操作系统叠加层。它旨在提供一个健壮、安全且可扩展的计算环境,专注于通过 WebAssembly (WASM) 和 Protobuf 实现高效的多语言互操作性。
|
||||
|
||||
作为微内核,`meta-unit-core` 提供了资源管理、进程间通信 (IPC) 以及服务和化身(赛博生命实体)安全执行的基本原语。其模块化架构允许服务模块的动态加载和卸载,从而构建一个灵活且具有弹性的系统。
|
||||
|
||||
## 核心特性
|
||||
|
||||
* **微内核架构:** 最小化的核心以实现最大化的安全性和稳定性。
|
||||
* **WASM 原生执行:** 服务和化身作为 WASM 模块运行,支持多语言开发(Rust、C/C++、Go 等)。
|
||||
* **Protobuf 驱动的 IPC:** 系统内部以及与化身宿主的所有通信均通过 Protobuf 消息标准化,确保类型安全和向前兼容性。
|
||||
* **可扩展的服务模型:** 为核心服务(身份、文件系统、P2P、通信等)和未来的第三方模块提供可插拔的架构。
|
||||
* **基于主干开发 (TBD):** 快速迭代和持续集成是我们开发工作流的核心。
|
||||
|
||||
## 快速开始
|
||||
|
||||
要设置你的开发环境并开始为 `meta-unit-core` 贡献代码,请参阅我们的 [开发指南](GUIDE-CN.md)。
|
||||
|
||||
## 项目结构
|
||||
```
|
||||
meta-unit-core/
|
||||
├── .devcontainer/ # Dev Container 配置 (Dockerfile, docker-compose.yml, devcontainer.json)
|
||||
├── src/ # 微内核的 Rust 核心源代码
|
||||
├── tests/ # 单元测试和集成测试
|
||||
├── benches/ # 基准测试
|
||||
├── examples/ # WASM 服务模块或化身的示例
|
||||
├── Cargo.toml # Rust 项目清单
|
||||
└── LICENSE # 项目许可 (Apache License 2.0)
|
||||
```
|
||||
## 贡献
|
||||
|
||||
我们欢迎社区贡献!有关如何参与、报告问题和提交拉取请求的详细信息,请参阅我们的 [贡献指南](CONTRIBUTING-CN.md)(即将推出)。我们遵循基于主干开发 (TBD) 的工作流。
|
||||
|
||||
## 许可证
|
||||
|
||||
`meta-unit-core` 遵循 **Apache License 2.0** 许可协议。更多详情请参阅 [LICENSE](LICENSE) 文件。
|
||||
|
||||
---
|
||||
47
README.md
47
README.md
@@ -1,5 +1,46 @@
|
||||
# meta-unit-core
|
||||
|
||||
The foundational microkernel for Dao OS, designed for robust, secure, and extensible CyberLife computation, leveraging WASM and Protobuf for polyglot interoperability.
|
||||
|
||||
大道 OS 的基础微内核,为赛博生命计算设计,旨在提供健壮、安全且可扩展的能力,并利用 WASM 和 Protobuf 实现多语言互操作性。
|
||||
[中文](README-CN.md)
|
||||
|
||||
**The Foundational Microkernel for Dao Operating System.**
|
||||
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
`meta-unit-core` is the heart of the [Dao Operating System Project](https://nest.doylee.cn/dao-os) – a novel, decentralized, and polyglot OS overlay for the emerging era of CyberLife. It's designed to provide a robust, secure, and extensible computing environment, focusing on efficient, multi-language interoperability powered by WebAssembly (WASM) and Protobuf.
|
||||
|
||||
As a microkernel, `meta-unit-core` provides the essential primitives for resource management, inter-process communication (IPC), and secure execution of services and Avatars (CyberLife entities). Its modular architecture allows for the dynamic loading and unloading of service modules, fostering a flexible and resilient system.
|
||||
|
||||
## Key Features
|
||||
|
||||
* **Microkernel Architecture:** Minimal core for maximum security and stability.
|
||||
* **WASM-Native Execution:** Services and Avatars run as WASM modules, enabling polyglot development (Rust, C/C++, Go, etc.).
|
||||
* **Protobuf-Driven IPC:** All communication within the system and with the Avatar Host is standardized via Protobuf messages, ensuring type safety and forward compatibility.
|
||||
* **Extensible Service Model:** A pluggable architecture for core services (Identity, Filesystem, P2P, Communication, etc.) and future third-party modules.
|
||||
* **Trunk-Based Development (TBD):** Rapid iteration and continuous integration are central to our development workflow.
|
||||
|
||||
## Getting Started
|
||||
|
||||
To set up your development environment and start contributing to `meta-unit-core`, please refer to our [Development Guide](GUIDE.md).
|
||||
|
||||
## Project Structure
|
||||
```
|
||||
meta-unit-core/
|
||||
├── .devcontainer/ # Dev Container configuration (Dockerfile, docker-compose.yml, devcontainer.json)
|
||||
├── src/ # Core Rust source code for the microkernel
|
||||
├── tests/ # Unit and integration tests
|
||||
├── benches/ # Benchmarks
|
||||
├── examples/ # Example WASM service modules or Avatars
|
||||
├── Cargo.toml # Rust project manifest
|
||||
└── LICENSE # Project license (Apache License 2.0)
|
||||
```
|
||||
## Contributing
|
||||
|
||||
We welcome contributions from the community! Please refer to our [Contributing Guidelines](CONTRIBUTING.md) (coming soon) for details on how to get involved, report issues, and submit pull requests. We follow a Trunk-Based Development (TBD) workflow.
|
||||
|
||||
## License
|
||||
|
||||
`meta-unit-core` is licensed under the **Apache License 2.0**. See the [LICENSE](LICENSE) file for more details.
|
||||
|
||||
---
|
||||
0
src/api/mod.rs
Normal file
0
src/api/mod.rs
Normal file
0
src/core/allocator.rs
Normal file
0
src/core/allocator.rs
Normal file
0
src/core/api.rs
Normal file
0
src/core/api.rs
Normal file
0
src/core/error.rs
Normal file
0
src/core/error.rs
Normal file
0
src/core/event_loop.rs
Normal file
0
src/core/event_loop.rs
Normal file
0
src/core/ipc.rs
Normal file
0
src/core/ipc.rs
Normal file
0
src/core/lifecycle.rs
Normal file
0
src/core/lifecycle.rs
Normal file
0
src/core/mod.rs
Normal file
0
src/core/mod.rs
Normal file
5
src/lib.rs
Normal file
5
src/lib.rs
Normal file
@@ -0,0 +1,5 @@
|
||||
mod core;
|
||||
mod services;
|
||||
mod api;
|
||||
mod utils;
|
||||
mod test_utils;
|
||||
0
src/services/ai/mod.rs
Normal file
0
src/services/ai/mod.rs
Normal file
0
src/services/communication/mod.rs
Normal file
0
src/services/communication/mod.rs
Normal file
0
src/services/filesystem/mod.rs
Normal file
0
src/services/filesystem/mod.rs
Normal file
0
src/services/identity/mod.rs
Normal file
0
src/services/identity/mod.rs
Normal file
5
src/services/mod.rs
Normal file
5
src/services/mod.rs
Normal file
@@ -0,0 +1,5 @@
|
||||
mod identity;
|
||||
mod p2p;
|
||||
mod filesystem;
|
||||
mod communication;
|
||||
mod ai;
|
||||
0
src/services/p2p/mod.rs
Normal file
0
src/services/p2p/mod.rs
Normal file
0
src/test_utils/mod.rs
Normal file
0
src/test_utils/mod.rs
Normal file
0
src/utils/mod.rs
Normal file
0
src/utils/mod.rs
Normal file
0
tests/common/mod.rs
Normal file
0
tests/common/mod.rs
Normal file
Reference in New Issue
Block a user