Open asomers opened 5 years ago
So much this.
Trying to use rust-fuse as a library crate is all but impossible atm. Would this be a better suited task for implementing a high-level API?
New to the library, and to Rust, and would really love to use rust-fuse in a project. Happy to contribute where I can.
Many thanks in advance.
Back then when rust-fuse was created, we intentionally chose to have no public constructors to ensure that implementations comply with what the kernel protocol requires. Nowadays the interface on the Rust side still works the same but looks a bit unusual. There's ongoing effort (e.g. in #90 and the modernize
branch) to make rust-fuse more idiomatic and especially add async and testing capability. I suppose that request and reply types will completely change so that this issue won't apply anymore. But afaik there is no issue specific to testability yet, so if you edit this issue to be more generic towards the new implementation, we could use it for collecting ideas and tracking progress of making fuse implementation testing easier.
I've been working on a new approach to testing crates that use rust-fuse. I'm using mockall
to create mock versions of each Request and Reply type. Then I have to redefine FileSystem
to take these mock types instead of the real ones. It's a lot of boilerplate, but it seems to work.
It would be nice to be able to unit test my filesystem's FUSE interface. Right now the only way to test it is to mount an actual filesystem and use the command line. But if rust-fuse did the following, then I would be able to write tests that hook into my filesystem's rust-fuse interface and exercise the whole API. This would require:
Default
forRequest
)Reply
types.Reply
types, for example to see the data stored byReplyData::data
.