Migrate to use fuse crate's FuseConfig API
The old API is deprecated with a new replacement in
https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3514617
Note that the original API uses write/read in an opposite perspective:
a write to the filesystem by another process is a read to these FUSE
filesystems. Which is also inconsistent to the mount opion of max_read.
The new API brings consistency. For this specific change:
- zipfuse happened to name them in the opposite (but now correct) way.
- authfs happened to use the same values for both, so just update the
comments. Also remove the comment in remote_file.rs that mentioned
the old API. It's not super helpful anyway with the compiler check.
Bug: 223659448
Test: atest AuthFsHostTest
Change-Id: I33436cdc3bf84c3a0d42a6b517fe9ef28958292a
diff --git a/authfs/src/fusefs.rs b/authfs/src/fusefs.rs
index 511db68..beb6b30 100644
--- a/authfs/src/fusefs.rs
+++ b/authfs/src/fusefs.rs
@@ -184,10 +184,9 @@
type DirHandleTable = BTreeMap<Handle, Arc<DirEntriesSnapshot>>;
-// AuthFS needs to be `Sync` to be accepted by fuse::worker::start_message_loop as a `FileSystem`.
+// AuthFS needs to be `Sync` to be used with the `fuse` crate.
pub struct AuthFs {
- /// Table for `Inode` to `InodeState` lookup. This needs to be `Sync` to be used in
- /// `fuse::worker::start_message_loop`.
+ /// Table for `Inode` to `InodeState` lookup.
inode_table: RwLock<BTreeMap<Inode, InodeState>>,
/// The next available inode number.