Created by: Alic3r3L1cwhk
This pull request adds extensive logging and improves partition support in the FAT32 filesystem and related modules. The main changes are the addition of detailed log statements throughout the block device, FAT32 filesystem, ELF loader, and process execution code to aid in debugging and tracing, as well as updates to support partition offsets when mounting FAT32 filesystems. Logging and Debugging Enhancements:
Added detailed log::info! statements throughout VirtIOBlkWrapper methods to trace block read/write submission, IRQ handling, and completion. Inserted extensive logging in Fat32FileSystem methods (e.g., read_sector, read_cluster, read_dir_entries_lfn, find_entry, open_file) to track sector/cluster operations, directory traversal, and file discovery. Improved logging in ELF loading (MemorySet::from_elf) and process execution (sys_exec, Task::exec) to provide visibility into ELF parsing, entry points, and execution arguments.
Partition Support and Filesystem Initialization:
Modified Fat32FileSystem to accept a partition_start_sector parameter, and updated all relevant methods (read_cluster, write_cluster, etc.) to compute absolute sector numbers using this offset. Updated FAT32 initialization functions and mount logic to handle partition offsets, passing partition_start_sector where needed and ensuring correct mounting of both whole-disk and partitioned filesystems.
Path and Filesystem Access Improvements:
Changed resolve_path to be public within the crate, and used it in sys_exec to resolve executable paths before mount lookup. Normalized file paths in the FAT32 mount implementation to ensure consistent access and creation semantics.
Test Case Debugging Progress (In Progress):
This PR is part of an ongoing effort to get BusyBox/LTP test cases running correctly on the current kernel. Through systematic logging and tracing, a number of previously suspected failure points have been investigated and ruled out, including block I/O paths, cluster/sector offset calculations, and ELF loading stages. The root cause of test case failures has not yet been fully identified, and end-to-end execution has not been verified. Further investigation is needed once this branch is merged and testable. Next steps include running the test cases against this build and observing whether the enhanced logging reveals remaining issues in path resolution, filesystem mounting, or process initialization.
These changes collectively improve the system's debuggability and robustness, especially when dealing with partitioned storage and complex file operations.