如何在不使用lib引信的情况下使用FUSE创建用户空间文件系统？

Question

我发现FUSE用户空间库和内核接口从Linux开始就已经移植到许多其他系统，并且呈现了一个相对稳定的API，其表面面积据称很小。如果我想在用户空间中创建一个文件系统，而且我不是计划9或Hurd，我会认为FUSE是我最好的选择。

但是，我不打算使用lib引信。这在一定程度上是因为实用主义；在我选择的语言中使用C是很困难的(Monte)。这也是因为我对编写C支持代码完全不感兴趣，而且lib引信的推荐用法与Monte哲学是不相容的。这不应该是个问题，因为C并不神奇，可以使用标准的系统调用打开/dev/fuse。

但是，我没有发现任何文档。我没有为/dev/fuse /API找到任何文档，也没有其他人使用这个非C路径的故事。令人沮丧。

关于如何以一种与语言无关的方式与/dev/fuse和内核的FUSE子系统交互，是否存在任何文档？如果是的话，你能指给我看吗？谢谢!

更新:存在go-fuse，它在Go中，这是一种比C更易读的语言，但是它也不包含任何ABI/API文档。

更新:我注意到人们投票决定关闭这个项目。别担心，没必要这么做。我确信我想要的文件还不存在。我将自己编写文档，发布它，然后在一个公认的答案中链接到它。希望下一个搜索这个文档的人不会失望。

Answer 1

(我不会接受这件事，直到它完成。在此期间，我们欢迎编辑！)

FUSE会议的基本大纲：

• open()在/dev/fuse上被调用。我将将产生的FD称为控件FD。
• mount()是用目标挂载点调用的，文件系统类型为"fuse“(普通模式)或"fuseblk”(块设备模式)，以及选项(包括"fd=X“，其中X是控制FD )。
• 熔断器特有的结构在控制FD上反复传输.通信的一般模式遵循请求-响应模式，其中程序read()的文件系统命令来自控制FD，然后是write()的响应。
• 使用目标挂载点调用umount()。
• 在控件FD上调用close()。

话虽如此，但还是有一些复杂的事情需要注意。首先，mount()几乎总是一个特权的syscall，所以您必须是根用户才能挂载FUSE文件系统。然而，正如人们可能已经注意到的，FUSE程序通常可以作为非根程序启动！多么?

有一个助手/bin/fusermount安装了setuid。使用完全没有记录，但这就是我来这里的目的。不要自己运行open() /dev/fuse，而是将fusermount作为子进程运行，将目标挂载点作为参数传递给目标挂载点，使用-o传递任何额外的挂载选项，以及(关键)使用环境变量_FUSE_COMMFD导出并设置为打开FD的ASCII字符串，我称之为comm 。您必须自己创建通信FD，例如使用pipe()。fusermount将为您调用open()和mount()，并使用用于共享FD的sendmsg()技巧，沿comm将控制FD共享给您。使用recvmsg()将其读回。

社论:我真的不明白为什么这是如此困难的结构。FDs是由子进程继承的；在最上面的进程中open()控制FD并将其传递到fusermount要容易得多。的确，存在一些混乱的副危险，但是fusermount已经安装好了，而且很危险。

无论如何，一旦主进程退出，fusermount将粗略地进行守护，并负责调用umount()和close()来清理。

尚未涵盖的事项：

• 如何处理对保险丝的非阻塞访问？控制FD能被踢成非阻塞模式吗？它实际上不是阻止，还是它的行为像一个普通的文件，并秘密阻止访问？
• 结构布局。这些可以或多或少地从C或Go源中重新发现，但这不是借口。当我想出足够多的受虐狂时，我会更认真地记录它们。