在我的 linux 中，从 posix lib 或内核调用了哪个版本的 close()？

Posted 2023-02-22

【中文标题】在我的 linux 中，从 posix lib 或内核调用了哪个版本的 close()？

【英文标题】：which version of close() is called in my linux,from posix lib or kernel?

【发布时间】：2012-06-29 06:27:16

【问题描述】：

当我man -a close 时，第一页是 POSIX 手册页，然后我有一个close(2)，（2 表示系统 api 或内核函数）。这意味着至少有 2 个版本的 close()。

例如，这样的一段代码：

int fd = open("xxx");
........
close(fd);   -----here, which version is called,
                  is that one from the POSIX lib, or the raw system API?

P.S.：因此我的 linux 系统包含一个用于大多数系统 API 调用的 POSIX 包装器，如何辨别我的代码是调用 POSIX lib 还是原始系统 API？

【参考方案1】：

POSIX 不是一个库，它是一个标准。手册页的 POSIX 版本告诉您 POSIX 标准所说的函数应该做什么（以及该页面基于哪个版本的 POSIX）。如果您只依赖本页中描述的行为，您的代码应该适用于所有实现 POSIX 标准的系统（只要它们实现了足够的最新版本）。

手册页的 Linux 版本告诉您该函数在您的系统上实际执行的操作。在绝大多数情况下，此处描述的行为将是 POSIX 页面中描述的行为的超集，即 Linux 行为将遵守 POSIX 标准，但它也可能定义 POSIX 未定义的情况或函数可能接受POSIX 未强制要求的其他选项。

如果您依赖 POSIX 未指定的任何行为，您的代码可能只能在 Linux 系统上运行。

【讨论】：

tks，s​​epp2k.你很清楚。POSIX不是一个库，它是一个标准-----------如果在linux中有一些最初不符合POSIX的行为， linux 是否会制作一些总结库来满足它？如果有的话，有什么例子吗？

POSIX 要求 close 作为取消点，而 Linux 内核对线程取消一无所知，因此 close 的用户空间 libc 包装器必须对其进行修补。

用户空间 libc wrapper for close _____ libc wrapper 是否为我们的应用程序包装了任何系统 api，例如，如果我们调用 close/open 或其他系统 api，我实际上首先调用 libc，然后 libc 为 usr 调用内核?如果是这样，libc为什么要存在？

【参考方案2】：

"这意味着至少有两个版本的 close()。"

没有。这意味着关闭的文档有 2 个版本。

【讨论】：

据我所知，有几种情况我们需要通过某种方式明确声明我们是使用 POSIX 还是 SYSTEMV 样式，（即使用信号量或线程时，等等......），在这些情况下这是否意味着linux为某些功能保留了两个实现？一个来自 POSIX，而其他的则符合一些旧风格？