为什么操作系统希望符合 POSIX 标准?

为什么操作系统希望符合 POSIX 标准?

POSIX 有什么大不了的以及它如何影响操作系统的整体使用?

答案1

一个合理的类比是学习驾驶。汽车和驾驶员都存在着规则、要遵循的协议以及质量和稳健性标准。

  • 汽车有方向盘。
  • 有些是手动档,有些是自动档。
  • 您(在大多数国家/地区)在道路的右侧行驶。
  • 标志提供有关如何在特定道路上行驶的指导。
  • 测量单位(大多数)是公里/小时。
  • 车辆所用的燃料具有一定的混合比和标准。
  • 司机经过培训并被期望遵守一定的驾驶标准。

现在,您可能会建议(虽然我没有那么有文化,并且给自己一些诗意的许可)欧洲的道路彼此“符合标准”,这样,如果您在西班牙学习驾驶,您就可以在欧洲的任何地方驾驶,可能使用同一辆车,或者至少可能是另一辆车,所有附加装置和操纵杆都在您期望的位置。

例如,您可以发明一种全新的驾驶方式,也许采用完全不同的标志,在道路两侧行驶,使用操纵杆驾驶,以肘尺/小时为单位测量距离,但是,从您习惯的系统迁移到该系统需要付出更多的努力。

POSIX 有点适合类似的模型,但它不是指汽车、道路、速度和目的地,而是指输入、消息、程序、输出和功能。

通常,作为程序员和用户,最好有一些管理特性/功能和输入/输出的规则,这样您就可以编写一个符合这些标准的程序,然后毫不费力地重建同一个程序以在不同的系统上运行,该系统也采用相同的输入/输出。

例如 Linux 系统调用符合 posix 标准。它们以特定顺序接收特定输入,并返回特定输出,同时根据规则控制输出在特定情况下可能是什么或代表什么。

您可以在 Linux 上编写一个程序,打开两个文件,使用readwrite在它们之间传输数据,然后再次关闭它们。然后可以重新构建它以在 Mac 上运行,而无需重写底层源代码。

但是,您也可以通过打开两个文件、使用系统调用在它们之间移动数据并再次关闭文件来执行完全相同的操作(速度要快得多sendfile)(除非您使用的是非常非常旧的内核)。这里的问题是系统sendfile调用不是POSIX 兼容——您无法保证这样的系统调用在系统上正确存在并可以执行您想要的操作。

事实上,如果你查看 Mac 手册页中的调用sendfile,虽然它被称为相同的操作,但它采用了不同的参数集并提供不同的功能(而且,从技术上讲,你实际上不能使用它从磁盘上的一个文件复制到磁盘上的另一个文件)。

sendfile因此,至少在不改变程序或使用其他兼容层的情况下,您将无法在系统上可预测地使用 Linux 运行程序。

这就是人们关心 POSIX 的原因。它避免了重新发明轮子,并可能允许您迁移到更好的整体“符合 POSIX”的操作系统,或者至少专注于交付您的产品,而不是担心构建基础所用材料的质量。

我跳过了许多关于 POSIX 并未真正完全遵循(甚至那些声称他们的系统符合 POSIX 的人也没有完全遵循)的争论,但这就是这个概念的要点。

最后我想澄清一点。如果你按照标准(如 POSIX)的最低标准进行编码,那么你将错失巨大的性能提升,而你本来可以通过在你正在编码的操作系统上使用非标准扩展来获得这些性能提升。

所以这也是一个设计选择,如果您追求高性能/高吞吐量,那么为了实现这一目标您可能不需要编写符合 POSIX 规范的代码。

尽管如此,雇用一名懂得如何“posixally”编程(懂得如何openread如何write pthreadclosePOSIX 中工作)的程序员要比雇用一名只会按照某些奇怪的未使用的标准进行编程的程序员要简单得多。

因此,这不仅仅与性能(汽车)有关,还与适应潜力(驾驶汽车的熟练程度)有关。

相关内容