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
• bounded provider RPC transport with in-flight reply polling for slower persistent backend calls
• 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 fmt
• cargo clippy --all-targets --all-features -- -D warnings
• cargo test --all-targets --all-features

Dynamic Boot Artifact Evidence

Phase 5.4.37 documents vfsd as a dynamic boot artifact. The image build packages the VFS service daemon as an ELF64 x86_64 ET_DYN executable with .erix_dynlink metadata in the signed dynlink-store and mirrors it under /lib/erix/dynlink with its required shared objects.

Startup remains rootd through procd staged dynamic creation before dynlinkd; authority remains explicit provider, memory, and loader peers. Dynamic packaging and filesystem mirror records are evidence and launch inputs only; they do not grant filesystem, loader, object-store, service-discovery, provider-bypass, block-device, or dynlinkd authority. vfsd receives only the documented startup endpoints, peers, and capabilities for its role.

Governance Principles

vfsd governance is scoped to the public VFS namespace and dispatch to private filesystem providers.

The scoped governance rules are:

• vfsd remains 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; long provider work remains bounded by the private-provider RPC timeout instead of granting callers direct provider authority.
• Filesystem providers stay private and receive no public client authority through vfsd.

Authority Boundaries

• vfsd receives only selected provider endpoints explicitly; it must not discover providers through named or 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.