Cleanup async interface and map 1:1 with Filesystem trait

[mhambre]

This PR takes the experimental async interface and cleans it up such that expansion can start to easily add new methods by mapping 1:1 with the Filesystem trait. This adds a call_fut! macro that sends the task to the tokio runtime, and automatically clones the request and a reference to the runtime to reduce boilerplate.

This is made with the goal in mind of next steps being expansion to include more mutation oriented operations, and orienting the async capabilities in a way that even further down the line this can be backed with AsyncFD, setting up an Async-oriented EventLoop, etc for full end-to-end async.

If this is accepted I can also take the initiative of starting to add the other missing FUSE methods to the async trait and building up a simple_async.rs example FS + tests.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 2343ac1881

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[mhambre]

#164

[mhambre]

@cberner Any thoughts on this when you get some time would be appreciated :)

[cberner]

I don't like this interface for async. One of my goals with the experimental async interface is to remove the need for Reply objects

[cberner]

I don't like this interface. I intentionally removed the Reply objects in the experimental async interface

[mhambre]

I don't like this interface. I intentionally removed the Reply objects in the experimental async interface

I appreciate your response and clarification. What would your thoughts be then on biting the bullet and decoupling it from the current Filesystem trait pretty much entirely (since as it stands, regardless of where it is Reply, will be blocking) and moving to the Result based approach for AsyncFD. I can also keep it the more minimal interface you were going for in the initial implementation. I know this is a bit of a step away from libfuse and a significant addition, but if we add async, I agree with the sentiment of being more rustic with Results since we aren't dealing with the same limitations. I'd obviously keep it as tightly scoped as possible for the initial PoC.

[cberner]

Ya, that sounds like it's aligned with the direction I want to take it. However, that's going to be a very large change, and I don't have time to review that right now. I'd encourage you to make a fork instead, and then circle back once you have it working and benchmark the performance