-
Notifications
You must be signed in to change notification settings - Fork 11
feat(fs): add layered VFS framework with RAM and device filesystem implementations #1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
|
Please clarify what this PR specifically improves, rather than just using AI generation. 😂 |
|
The three test files verify the modular file system framework through a layered policy, which improves the reliability, compatibility, and scenario coverage of the framework: test_axfs_vfs.rs ensures that the VFS interface rules and infrastructure are correct, and avoids common errors in file system implementation from the bottom level; test_axfs_ramfs.rs verifies the processing of common operations and boundary conditions of the general memory file system to ensure the integrity and robustness of the standard file system functions. test_axfs_devfs.RS tests the device behavior simulation and permission restriction rules of the special device file system, covering the customized logic and security constraints of the device management scenario, and jointly builds a full-link verification system from basic specifications to special scenarios. However, there is a repetition and the original test file needs to be modified |
|
The introduction of these two comprehensive integration test suites (along with fixing the previous duplicates) provides a solid guarantee for the correctness and robustness of the two file system modules, RAMFS and DevFS. Instead of testing in isolation, we systematically verify the core functions of the whole lifecycle, such as file creation, read and write, path resolution, and deletion, by building complex scenarios that include multi-layer directories and different node types (common files and special devices), ensuring that they can work together and meet expectations under various conditions. |
|
At the same time, the problem of nightly has been fixed |
|
|
||
| // --- Perform strict node identity checks using Arc::ptr_eq --- | ||
| assert!(Arc::ptr_eq( | ||
| &foo.clone().lookup("f2").unwrap(), // Note: lookup from `foo`, not `/f2` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Remove unnecessary clones.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Roger that
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please try to improve upon existing tests to minimize code changes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, trying it
These three test files (test_axfs_vfs.rs, test_axfs_ramfs.rs, test_axfs_devfs.rs) collectively form a layered and well-defined testing strategy, perfectly demonstrating how to write unit tests for a modular filesystem framework. They validate the Interface Layer, the In-Memory Implementation Layer, and the Device Implementation Layer, respectively.
Core Goal: To verify the correctness of the axfs_vfs crate itself. This crate defines the "contract" (traits) that all filesystems must adhere to and the foundational utilities they rely on. These tests ensure that the "rules of the game" for the filesystem are clear and correct.
What it Tests:
Core Data Structures (test_vfs_data_structures): Confirms that core data structures like file/directory attributes (VfsNodeAttr), permission bits (VfsNodePerm), and node types (VfsNodeType) behave as expected. For instance, it checks if permission bits can correctly represent rwxr-xr-x.
Core Utility Functions (test_path_canonicalization): Specifically tests the path normalization utility (path::canonicalize) to ensure it correctly handles various complex and non-standard paths (e.g., ///a/./b/../c).
Developer Helper Macros (test_default_impl_macros): Verifies that the helper macros provided to developers (like impl_vfs_dir_default) work as intended, ensuring they automatically implement the correct error-handling logic for nodes (e.g., performing a read on a directory should return an IsADirectory error).
Core Goal: To validate that RamFileSystem, as a concrete VFS implementation, has correct logic for its in-memory operations. It focuses on how files and directories are actually created, looked up, read, written, and deleted in memory.
What it Tests:
Path Traversal and Lookup (test_path_manipulation_and_lookup): Tests the lookup operation within a predefined directory tree. It verifies that ramfs can correctly handle ., .., and redundant slashes to find nodes within its in-memory data structures.
File I/O Edge Cases (test_io_edge_cases): Rigorously tests various edge cases for file I/O operations (read_at, write_at, truncate). For example: writing past the end of a file (should be zero-padded), reading beyond the end of a file (should only return the valid portion), and truncating a file to make it larger or smaller.
Error Condition Handling (test_error_conditions): Ensures that ramfs returns the correct error types defined in axfs_vfs when encountering invalid operations. For example, creating a file that already exists should return AlreadyExists, and deleting a non-empty directory should return DirectoryNotEmpty.
Core Goal: To verify that DeviceFileSystem, as another special-purpose VFS implementation, correctly manages and simulates special device files. The test focuses on the intrinsic properties of the virtual devices and the filesystem's read-only structure.
What it Tests:
Standard Device Behavior (test_root_device_operations): Verifies that core devices (like /dev/null and /dev/zero) behave according to standards. For example, writing to /dev/null should succeed but have no effect, while reading from /dev/zero should return an infinite stream of zero bytes.
Directory Structure and Traversal (test_subdirectory_and_path_traversal): Confirms that devfs supports subdirectory creation and can correctly resolve complex paths within a nested structure to find the corresponding device nodes.
Permission and Error Handling (test_error_conditions): Validates the operational constraints of devfs. Most importantly, it confirms that any attempt to create (create) or remove (remove) nodes at runtime is correctly rejected (returning PermissionDenied), as the structure of devfs is typically fixed at initialization.