- Rust 99.7%
- Linker Script 0.3%
| .github | ||
| src | ||
| .editorconfig | ||
| .gitignore | ||
| .markdownlint-cli2.yaml | ||
| ARCHITECTURE.md | ||
| Cargo.toml | ||
| CODE_OF_CONDUCT.md | ||
| CONTRIBUTING.md | ||
| LICENSE | ||
| linker.ld | ||
| README.md | ||
| ROADMAP.md | ||
| rustfmt.toml | ||
| SECURITY.md | ||
vfsd
vfsd is the public virtual filesystem daemon that owns the EriX filesystem
namespace and dispatches mounted paths to private providers.
EriX is a clean-room, capability-based microkernel operating system written entirely in Rust.
Technical requirements are tracked in the EriX requirements, conventions, and project documentation.
See:
- docs for design documents, specifications, and development plans.
- Related architecture repositories for kernel, services, libraries, drivers, and integration tooling.
Purpose of This Repository
This repository implements the EriX virtual filesystem service. Its purpose in EriX is to own the public filesystem namespace while delegating media-specific work to private providers.
Functionally, it routes VFS operations to mounted provider backends and keeps provider authority private. The repository keeps the implementation, interface contracts, tests, and documentation for that behavior in one reviewable ownership boundary.
The maintained responsibilities are:
- provide the single public filesystem namespace service
- route mounted paths to private filesystem providers through bounded provider endpoints
- validate mount, path, handle, and operation authority before dispatch
Clean-Room Policy
EriX follows a strict clean-room philosophy:
- No external source code may be copied.
- No external Rust crates are allowed.
- No code generation tools that embed third-party code.
- All code must be authored within the project.
Violations will result in rejection of the contribution.
License
All EriX repositories are licensed under the ISC License.
Development Model
EriX development is modular, deterministic, reproducible, authority-explicit, security-first, and self-hosting oriented.
This repository follows the project roadmap and the validation rules documented in its own roadmap.
Status
Implemented baseline for the VFS service path:
- public VFS op dispatch for mount, metadata, file I/O, and directory I/O
- additive namespace dispatch for rename, truncate, symlink/readlink, hard-link request forwarding, and flagged metadata updates
- provider table setup for selected volatile-memory, EXT, FAT, FAT12, FAT16, and exFAT provider kinds
- UTF-8 namespace path/name validation with unchanged v1 wire layout
- root-first mount policy
- synthetic mount-overlay visibility in parent directory reads
- handle lifecycle validation
- unit coverage for startup validation, mount-table rules, namespace behavior, extended namespace operations, and backend forwarding
Validation
cargo fmtcargo clippy --all-targets --all-features -- -D warningscargo test --all-targets --all-features
Governance Principles
vfsd governance is scoped to the public VFS namespace and dispatch to private
filesystem providers.
The scoped governance rules are:
vfsdremains the only public filesystem service endpoint.- Mounts must bind explicit paths, filesystem types, provider endpoints, and block-device identifiers.
- Provider dispatch must preserve path canonicalization, handle ownership, and operation bounds.
- Filesystem providers stay private and receive no public client authority
through
vfsd.
Authority Boundaries
vfsdreceives only selected provider endpoints explicitly; it must not discover providers throughnamedor ambient lookup.- New provider types require documented routing and boot-config mount rows before they can be mounted.
Contact
Development occurs in EriX organization and discussions happen in issues and design documents.
No decisions are considered valid without documented rationale.
Maintainers can be reached via email: admin@erikinkinen.fi.