Flint's filesystem is a userspace subsystem.
The kernel does not fundamentally understand files, directories, paths, mounts, or filesystem semantics. Filesystem functionality is implemented by userspace services that use kernel-provided mechanisms and capabilities.
Philosophy
Userspace filesystem
The filesystem should run in userspace rather than being implemented as a kernel subsystem.
The kernel provides the resources and mechanisms required for filesystem services to operate, while userspace defines filesystem semantics.
Files are not universal resources
flint does not follow the Unix principle that everything is a file.
A file is a userspace abstraction. Not every resource needs to have a filesystem representation.
Resources such as devices, processes, memory, and kernel state can instead be accessed through capabilities and IPC.
A userspace service may choose to represent a resource as a file when doing so is useful.
Unix-inspired, not Unix-compatible
Flint's filesystem is inspired by the Unix filesystem model but is not required to preserve Unix or POSIX semantics.
Familiar concepts such as files, directoreis, paths and hierarchical storage may be retained where they provide a useful model.
Unnecessary historical complexity may be removed or simplified.
Principle: Borrow ideas, not obligations.
Filesystem hierarchy
Flint currently uses the following top-level hierarchy:
/
├── bin
├── boot
├── conf
├── data
├── home
├── lib
└── run
/
The root of the filesystem hierarchy.
/bin
Contains executable programs and binaries.
/conf
Contains system-wide configuration
This replaces the traditional Unix/Linux /etc.
/data
Contains general persistent data that is owned by the system or its userspace services and is not specific to an individual user.
This combined concepts traditionally separated between /usr, /var, and /srv.
/home
Contains user-specific data.
The root user's home directory is: /home/root
There is no separate /root directory.
/lib
Contains libraries and supporting runtime code.
Flint targets RV64, so a separate /lib64 hierarchy is unnecessary.
/run
Contains volatile runtime data
This is data that exists for currently running processes and does not need to persist as apart of the permanent filesystem state.
This includes both traditional runtime state and temporary data.
Examples include:
- Runtime sockets
- Locks
- Process state
- Temporary files
- Other process-owned transient data
There is no separate /tmp hierarchy.
System information
System and hardware information are not inherently represented as files.
the filesystem does not provide kernel information merely because Unix traditionally exposes it through /proc or /sys.
Instead, userspace services obtain authorized information through IPC and other kernel mechanisms.
A userspace service may subsequently choose to present that information through a filesystem interface.
Devices
Devices are resources rather than inherently being files.
Flint therefore has no kernel-provided /dev filesystem.
A userspace service may provide a filesystem representation of devices where useful, but the kernel does not need to understand device files or /dev.
Runtime and persistence
Flint distinguishes persistent data from volatile runtime data.
/run may be backed by volatile storage such as tmpfs, while /data is intended for persistent storage.
The physical storage mechanism is separate from the filesystem namespace. The distinction is semantic rather than a requirement about the underlying storage technology.
/data organization
/data uses a service-oriented layout.
Persistent data should generally be grouped according to the userspace service that owns and manages it rather than according to generic categories such as log, cache, or lib.
For example:
/data/
├── filesystem/
├── network/
├── init/
└── ...
A service may organize its own directory internally according to its needs.
This keeps ownership explicit and avoids imposing a universal data taxonomy on userspace services.
Principle: Persistent data belongs to the service that owns it.