我正在研究 Linux FUSE。
现在我了解了 FUSE 的整体架构以及 libfuse、/dev/fuse 设备文件是什么。但我找不到有关应用程序进程和 FUSE 文件系统守护进程之间的进程通信的详细信息。所以我分析了 fuse 代码。
看起来 fuse 使用等待队列和文件在两个进程之间进行通信。等待队列用于发送信号。文件用于发送/接收请求内容。对吗？
如果我的分析正确，为什么 fuse 要使用文件？为什么不使用其他 IPC？文件看起来比其他 IPC 机制慢...
我的问题不是用户级的 IPC。内核-用户空间接口部分https://www.kernel.org/doc/Documentation/filesystems/fuse.txt，有一个示例 rm 应用程序和 Fuse 文件系统守护程序。两个进程使用 request_send()、request_receive() 函数进行通信。所以我分析了这些函数。我想知道这些函数是如何工作的。谢谢。
答案1
FUSE 使用文件系统 API，因为 FUSE 的整个目的是为进程提供文件系统 API。
假设您有一个访问文件的程序。它将使用文件系统 API，因为这是程序访问文件的方式。现在，假设您希望该程序与 FUSE 一起工作。FUSE 必须为该进程提供文件系统 API，因为这是该程序正在使用的，我们不想为了让 FUSE 工作而修改系统上的每个程序。您不必为任何其他文件系统重写程序。
想象一下，如果一个文件系统使用自己的 API，而你希望它能够使用文件系统上的文件，你就必须修改系统上的每个程序，那将是多么糟糕。真恶心。
如果我的分析是正确的，为什么要使用 fuse ues 文件？为什么不使用其他 ipc？文件看起来比其他 ipc 机制慢...
为什么会这样呢？请记住，我们讨论的不是磁盘上的文件。我们讨论的是文件作为 IPC 机制的概念。也就是说，进程 A 告诉进程 B 它想要使用调用来打开文件，open或者它想要使用调用来写入文件write。为什么这会比使用任何其他调用都慢？这些函数的实现可以是任何我们想要的。