FUSE缓存驱动：open(2)自定义标志传递失败及替代方案问询

自定义标志位被剥离的原因与源码位置 #

Linux内核在处理open(2)系统调用时，会严格校验传入的flags参数，仅保留内核预定义的合法标志位（如O_RDONLY、O_WRONLY等），自定义的未被内核认可的标志位会被直接剥离，不会传递到FUSE驱动的.open处理函数。

相关核心源码位置：

• 系统调用入口：fs/open.c中的do_sys_open函数，会通过valid_fd_flags宏（定义在include/linux/fs.h）过滤非法标志位。
• FUSE内核模块：fs/fuse/file.c里的fuse_open函数，最终传递给用户态FUSE驱动的flags是经过内核过滤后的结果，并非应用层原始传入值。

替代传递方案 #

如果无法通过自定义open标志位传递信息，可以采用以下几种常用方案：

• 自定义ioctl命令：定义专属的ioctl控制码，应用层在调用open后，通过ioctl向FUSE驱动传递读取模式等提示信息，驱动实现.ioctl处理函数接收并解析。
• 扩展文件属性（xattrs）：应用层使用setxattr设置目标文件的自定义扩展属性（如user.read_mode），FUSE驱动在.open或.read处理逻辑中，通过getxattr读取该属性获取提示。
• 辅助文件机制：在目标文件所在目录下创建命名规则化的辅助文件（例如.hint_<目标文件名>），将提示信息写入其中，FUSE驱动在处理目标文件的操作时，读取该辅助文件的内容作为提示。
• fcntl自定义命令：利用fcntl系统调用传递自定义控制信息，FUSE驱动实现.fcntl处理函数来接收和处理这些信息。

内容的提问来源于stack exchange，提问作者sighingnow