LWN：用在文件系统上的flags已经一团乱了！

关注了就能看到更多这么棒的文章哦～

Filesystem-oriented flags: sad, messy and not going away

By Jonathan Corbet
March 16, 2020

原文来自：https://lwn.net/Articles/815118/

过去十多年里人们开始大量采用同一种做法：就是在各个新增的系统调用里面加上了"flags"参数，甚至哪怕并没有真正用起来，也会先加上再说。好的方面，这确实有助于增强API的可扩展性，不过我们我也看到一些相关系统调用里增加了许多各种各样的flags。尤其是在file和filesystem相关的系统调用里，flags太多了，许多调用甚至需要使用3个参数位置来设置flags。

了解Unix系统调用API的朋友都很熟悉一组用在文件系统上的flags：o_flags，用在open()等调用中。这些flags会影响系统调用的具体行为，例如O_CREAT会在文件不存在的时候创建并打开，O_NOFOLLOW发现文件名指向的是个符号链接的时候就直接返回错误，O_NONBLOCK要求这个操作不能阻塞，等等。其中一些flag会影响文件查找过程（比如O_NOFOLLOW），一些flag例如O_NONBLOCK则会影响拿到的文件描述符今后的具体行为。这些都定义在同一个flag namespace里，所有open()类似的系统调用都会支持。

要在目录中创建新的项目的话，open()只是其中一种方式，link()也可以做到。当人们要给link()增加flags的时候，就创建了linkat()系统调用，它采用了一种新式方法来拿到目录对应的文件描述符。linkat()有一组跟此前不同的flag（AT_flags），比如AT_SYMLINK_FOLLOW，这个含义其实刚好跟O_NOFOLLOW相反。还有一个AT_SYMLINK_NOFOLLOW，不过linkat()并不支持这个flag，只有fchmodat()和execveat()这种API才支持。还有许多其他的AT_flags，比如AT_NO_AUTOMOUNT，用在新近的statx()系统调用上。

后来又有了openat2()，这是在5.6 kernel中的API。它没有用一个单独的flag参数，而是要求提供一个指向open_how结构的指针：

    struct open_how {
	__u64 flags;
	__u64 mode;
	__u64 resolve;
    };

其中的flags就是包括那些open()系列函数所用的O_flags，而resolve则是另一组flags（称为RESOLVE_flags），包括RESOLVE_BENEATH，限制只能查找指定目录之下的文件，RESOLVE_NO_SYMLINKS则是有点类似O_NOFOLLOW或者AT_SYMLINK_NOFOLLOW的，不过有区别，它会在解析路径节点的过程中任何阶段都会阻止展开符号链接，而不是只看最后一个节点是不是符号链接。

LWN此前介绍过fsinfo()系统调用的来龙去脉。它是用来提供mount上来的文件系统的信息的。这个新API也包括一个结构指针作为参数：

    struct fsinfo_params {
	__u32	at_flags;
	__u32	flags;
	__u32	request;
	__u32	Nth;
	__u32	Mth;
	__u64	__reserved[3];
    };

这里的at_flags就是指前面讲过的AT_flags，而flags则是此API专用的另一组flag。最近fsinfo()的作者David Howells说有人告诉他在新的系统调用上不应该用AT_flags，而是应该用RESOLVE_flags，所以他文是不是AT_flags已经算作deprecated（即将废弃）状态了。后来他提了一个patch把AT_flags标为deprecated，然后增加了一些RESOLVE_flags来覆盖一些暂时未有支持的AT_flags功能。比如，增加了RESOLVE_NO_TERMINAL_SYMLINKS（后来又改名为RESOLVE_NO_TRAILING_SYMLINKS），实现了AT_SYMLINK_NOFOLLOW的相同作用。

Christian Brauner也比较喜欢RESOLVE_flags，认为除了openat()之外今后其他地方可能也会用到一些RESOLVE_flags特有的含义。不过他也认为“我们需要避免再让userspace看到一组新的flags感到混淆了”，不过其他人觉得现在担心这个可能有点晚了。

不过Linux Torvalds不太喜欢把AT_flags标为deprecated的注意。他认为软件会继续使用O_NOFOLLOW或者AT_SYMLINK_NOFOLLOW，不能简单把它们删掉。他补充说：

And yes, the fact that we then have three different user-visible namespaces (O_xyz flags for open(), AT_xyz flags for linkat(), and now RESOLVE_xyz flags for openat2()) is sad and messy. But it's an inherent messiness from just how the world works. We can't get rid of it.

（大意：现在我们有3组flags用在各种API上，确实有点太乱了，不过这是现实世界里的继承问题，我们没法简单删掉）

他说，用多种flag来实现类似的一组功能，这会导致许多复杂性，让人们搞不清楚该怎么用。我们可以认为他的意思是所有这类patch今后都无法合入mainline。后来他又说，如果fsinfo()既需要AT_flags也需要RESOLVE_flags的功能，那么fsinfo()就应该能接受这两种flags。这样再加上它自己特有的flag，就是一个API带有3种flags了。可以预料，按这种做法的话，今后如果要实现个openat2()来使用AT_flag的话，那么它也需要接受第三种flag了。

这种情况确实比较“sad and messy”，看起来短时间内也不会怎么变好。这个API其中最乱的一点，就是它对这些flags没有进行类型检查。开发者只有靠自己小心检查来避免自己把flag填错位置了。这一点在今后也很难改变了，哪怕有人愿意修改也没用，因为要保证向后兼容。这还不是咱们这么多API里面设计的最乱的一个，只能先继续带病生存了。

全文完

LWN文章遵循CC BY-SA 4.0许可协议。

欢迎分享、转载及基于现有协议再创作～

长按下面二维码关注，关注LWN深度文章以及开源社区的各种新近言论～