Development and Project Setup
Relevant source files
This document provides essential information for developers working on or with the memory_set crate, covering project dependencies, build configuration, supported targets, and development workflows. For implementation details and API usage, see Implementation Details and Usage and Examples.
Project Overview and Structure
The memory_set crate is designed as a foundational component within the ArceOS ecosystem, providing no_std compatible memory mapping management capabilities. The project follows standard Rust conventions with additional considerations for embedded and OS development environments.
Project Structure and Dependencies
flowchart TD
subgraph Licensing["Licensing"]
LIC["GPL-3.0-or-later OR Apache-2.0 OR MulanPSL-2.0"]
end
subgraph Categorization["Categorization"]
KW["keywords: [arceos, virtual-memory, memory-area, mmap]"]
CAT["categories: [os, memory-management, no-std]"]
end
subgraph subGraph2["External Dependencies"]
MA["memory_addr = 0.2"]
end
subgraph subGraph1["Package Metadata"]
PN["name: memory_set"]
PV["version: 0.1.0"]
PE["edition: 2021"]
PA["author: Yuekai Jia"]
end
subgraph subGraph0["Project Configuration"]
CT["Cargo.toml"]
CI[".github/workflows/ci.yml"]
end
CT --> CAT
CT --> KW
CT --> LIC
CT --> MA
CT --> PA
CT --> PE
CT --> PN
CT --> PV
Sources: Cargo.toml(L1 - L16)
The crate maintains minimal external dependencies, requiring only the memory_addr crate for address type definitions. This design choice supports the no_std environment requirement and reduces compilation complexity.
| Configuration | Value | Purpose |
|---|---|---|
| Edition | 2021 | Modern Rust language features |
| Categories | os,memory-management,no-std | Ecosystem positioning |
| License | Triple-licensed | Compatibility with various projects |
| Repository | github.com/arceos-org/memory_set | Source code location |
| Documentation | docs.rs/memory_set | API documentation |
Sources: Cargo.toml(L1 - L16)
Build Configuration and Target Support
The project supports multiple target architectures, reflecting its intended use in diverse embedded and OS development scenarios. The build configuration accommodates both hosted and bare-metal environments.
Supported Target Architectures
flowchart TD
subgraph subGraph2["Bare Metal Targets"]
X86N["x86_64-unknown-none"]
RISCV["riscv64gc-unknown-none-elf"]
ARM64["aarch64-unknown-none-softfloat"]
end
subgraph subGraph1["Hosted Targets"]
X86L["x86_64-unknown-linux-gnu"]
end
subgraph subGraph0["CI Target Matrix"]
RT["nightly toolchain"]
end
RT --> ARM64
RT --> RISCV
RT --> X86L
RT --> X86N
Sources: .github/workflows/ci.yml(L11 - L12)
The build process includes several validation steps:
| Step | Command | Purpose |
|---|---|---|
| Format Check | cargo fmt --all -- --check | Code style enforcement |
| Linting | cargo clippy --target TARGET --all-features | Static analysis |
| Build | cargo build --target TARGET --all-features | Compilation verification |
| Testing | cargo test --target TARGET | Unit test execution |
Sources: .github/workflows/ci.yml(L23 - L30)
Toolchain Requirements
The project requires the nightly Rust toolchain with specific components:
rust-src: Required for no_std target compilationclippy: Static analysis and lintingrustfmt: Code formatting enforcement
Toolchain Setup Process
sequenceDiagram
participant Developer as Developer
participant CISystem as CI System
participant RustToolchain as Rust Toolchain
participant TargetBuild as Target Build
Developer ->> CISystem: "Push/PR trigger"
CISystem ->> RustToolchain: "Install nightly toolchain"
RustToolchain ->> CISystem: "rust-src, clippy, rustfmt components"
CISystem ->> RustToolchain: "rustc --version --verbose"
loop "For each target"
CISystem ->> TargetBuild: "cargo fmt --check"
CISystem ->> TargetBuild: "cargo clippy --target TARGET"
CISystem ->> TargetBuild: "cargo build --target TARGET"
alt "x86_64-unknown-linux-gnu only"
CISystem ->> TargetBuild: "cargo test --target TARGET"
end
end
Sources: .github/workflows/ci.yml(L14 - L30)
Development Workflow and CI Pipeline
The continuous integration system enforces code quality standards and validates functionality across all supported targets. The workflow is designed to catch issues early and maintain consistency.
CI Job Configuration
The CI pipeline consists of two primary jobs:
- Main CI Job (
ci): Validates code across all target architectures - Documentation Job (
doc): Builds and deploys API documentation
CI Pipeline Architecture
flowchart TD
subgraph subGraph5["Documentation Job"]
DOCBUILD["cargo doc --no-deps"]
DEPLOY["Deploy to gh-pages"]
end
subgraph subGraph4["Validation Steps"]
FMT["cargo fmt --check"]
CLIP["cargo clippy"]
BUILD["cargo build"]
TEST["cargo test (linux only)"]
end
subgraph subGraph3["CI Job Matrix"]
subgraph Targets["Targets"]
T1["x86_64-unknown-linux-gnu"]
T2["x86_64-unknown-none"]
T3["riscv64gc-unknown-none-elf"]
T4["aarch64-unknown-none-softfloat"]
end
subgraph Toolchain["Toolchain"]
NIGHTLY["nightly"]
end
end
subgraph subGraph0["Trigger Events"]
PUSH["push events"]
PR["pull_request events"]
end
CI["CI"]
BUILD --> TEST
CI --> DOCBUILD
CLIP --> BUILD
DOCBUILD --> DEPLOY
FMT --> CLIP
NIGHTLY --> T1
NIGHTLY --> T2
NIGHTLY --> T3
NIGHTLY --> T4
PR --> CI
PUSH --> CI
T1 --> FMT
T2 --> FMT
T3 --> FMT
T4 --> FMT
Sources: .github/workflows/ci.yml(L1 - L56)
Documentation Generation
The documentation workflow includes specialized configuration for maintaining high-quality API documentation:
- RUSTDOCFLAGS:
-D rustdoc::broken_intra_doc_links -D missing-docs - Deployment: Automatic GitHub Pages deployment on main branch
- Index Generation: Automatic redirect to crate documentation
Sources: .github/workflows/ci.yml(L40 - L48)
Testing Strategy
Testing is performed only on the x86_64-unknown-linux-gnu target due to the hosted environment requirements for test execution. The test command includes --nocapture to display output from test functions.
Test Execution Conditions
flowchart TD START["CI Job Start"] CHECK_TARGET["Target == x86_64-unknown-linux-gnu?"] RUN_TESTS["cargo test --target TARGET -- --nocapture"] SKIP_TESTS["Skip unit tests"] END["Job Complete"] CHECK_TARGET --> RUN_TESTS CHECK_TARGET --> SKIP_TESTS RUN_TESTS --> END SKIP_TESTS --> END START --> CHECK_TARGET
Sources: .github/workflows/ci.yml(L28 - L30)
ArceOS Ecosystem Integration
The memory_set crate is positioned as a foundational component within the broader ArceOS operating system project. This integration influences several design decisions:
- Homepage: Points to the main ArceOS project (
github.com/arceos-org/arceos) - Keywords: Include
arceosfor discoverability within the ecosystem - License: Triple-licensing supports integration with various ArceOS components
- No-std Compatibility: Essential for kernel-level memory management
Sources: Cargo.toml(L8 - L12)
The minimal dependency footprint and broad target support make this crate suitable for integration across different ArceOS configurations and deployment scenarios.