fusefs: add a simple in-memory file system for the tests

[asomers]

Summary

Some tests previously depended on fuse-ext2 from ports. Remove the
dependency on ports by adding a native, simple in-memory file system to
the test suite.

MFC after: 2 weeks
Sponsored by: ConnectWise

[asomers]

@arrowd what do you think of this? If we merge it, then we can eliminate my depedence on fuse-ext2 and your dependence on fuse-hello.

[arrowd]

tests/sys/fs/fusefs/integration.sh

62

It might worth testing that the copied binary actually runs, maybe?

62

Another thing that I worry about is making sure nosuid works. This memfs test seems to be a good place to do that.

tests/sys/fs/fusefs/memfs.cc

33

All "real" FUSE daemons are libfuse-based and using this memfs thingie will leave the libfuse integration untested. Moreover, the only test that is currently failing in my review is due to bug on the libfuse side, which would otherwise would be left unnoticed. Finally, the usermount logic is consolidated in mount_fusefs, and memfs performs mounting on its own.

So, I think memfs and fusefs-hello_ll take too different approaches and both worth to be tested.

794

Why dynamically allocate these?

[asomers]

tests/sys/fs/fusefs/integration.sh

62

That's enforced above the layer of individual file systems. And in fact we do have test coverage for nosuid now, ever since 8fd4d1c0fff8441b42dbab767810db7aeaf796c3 .

62

It does check that the binary runs. atf_check verifies that the command's exit status is ok.

tests/sys/fs/fusefs/memfs.cc

33

Not "all". For example, the most popular FUSE libraries for Rust don't use libfuse.

Your point about mount_fusefs is a good one. We should modify memfs to use it. What would memfs's main function look like in that case? I think it wants to see /dev/fuse already opened, with the file descriptor provided in the FUSE_DEV_FD variable, and mount_fuse handles calling nmount, leaving the fuse_daemon to handle FUSE_INIT, correct?

794

Because they're huge, thanks to the "bytes" fields in the payloads union.

[arrowd]

tests/sys/fs/fusefs/memfs.cc

33

Judging from the truss output, no:

7535: execve("/sbin/mount_fusefs",
    [ "mount_fusefs", "-o", "fsname=hello_ll", "3", "/tmp/foo" ],
    [ "MOUNT_FUSEFS_CALL_BY_LIB=1", "MOUNT_FUSEFS_SAFE=1"]

The caller opens /dev/fuse and passes the fd as "special".

794

At least std::vector manages its own storage and allocates on heap internally. You probably meant std::array there?

[asomers]

tests/sys/fs/fusefs/memfs.cc

794

Oh, I see what you mean. Yeah, I needn't have allocated the vector on the heap.

[asomers]

• Don't heap-allocate a std::vector
• Use mount_fusefs with memfs