Make the fs Backend dyn-compatible#963
Conversation
wdcui
left a comment
There was a problem hiding this comment.
LGTM. Thanks!
GPT-5.5 reported the following two findings. Please double check them.
-
litebox/src/fs/resolver.rs: O_PATH is accepted, but normal operations on those fds hit unimplemented!(), so a caller can panic LiteBox instead of getting an errno-style error such as EBADF.
-
litebox/src/fs/devices.rs: The devices backend gives / and /dev the same (dev, ino): dev_dir_inode starts at inode 0, and root status also reports inode 0. This breaks inode identity for distinct directories.
7483b4a to
7490029
Compare
|
Thanks, the
For the inodes for the dirs, yep, known and will be resolved in future PRs, see #887 (review) |
|
🤖 SemverChecks 🤖 Click for details |
#887 introduced the
Backendabstraction to the file system, but as I was working on more functionality, I discovered that the better design is to guarantee thatBackendis dyn-compatible, so that the composition of multiple backends can be done without a huge amount of type-level machinery + macros; it also keeps the interfaces more ergonomic for consumers of LiteBox core. To make things dyn-safe, we need to move out theBackend-specific handles; however, rather than the naive handling of this, there's a convenient abstraction such that backend implementations still end up with a largely convenient way to use their own typed handles.