syscall包

本文翻译自《The syscall package》。

作者：Rob Pike 日期：2014

状态：此提案[Go 1.4版本采用] (https://go.dev/doc/go1.4#major_library_changes)。

问题

现在的syscall包有几个问题：

1.膨胀。它包含许多系统调用和常量的定义，用于大量且不断增长的体系结构和操作系统。

2.测试。很少有接口有明确的测试，跨平台测试是不可能的。

3.管理。许多更改列表到来，以支持范围广泛的包和系统。这些变化的优点很难判断，所以基本上任何事情都会发生。该软件包是标准存储库中维护最差、测试最差、文档最差的软件包，并且还在继续恶化。

4.文档。称为syscall的单个包对于每个系统都不同，但godoc仅显示其本机环境的变体。此外，无论如何，文档都非常缺乏。大多数函数根本没有文档注释。

5.兼容性。尽管有最好的意图，但该软件包不符合Go 1兼容性保证，因为操作系统的变化方式超出了我们的控制范围。最近对FreeBSD的更改就是一个例子。

这个提议是试图改善这些问题。

提议

该提案有几个组成部分。没有特别的顺序：

1.Go 1的兼容性规则意味着我们不能直接解决问题，比如通过使包内部化。因此，我们建议从Go 1.3开始冻结该包，这意味着取消从那时起进行的一些更改。

2.支持Go未来版本所需的系统调用接口的任何更改都将通过为Go 1.4提议的内部包机制完成。

3.syscall包将不会在未来的版本中更新，甚至不会跟上它引用的操作系统的变化。例如，如果内核常量的值在未来的NetBSD版本中发生变化，则不会更新syscall包以反映这一点。

4.将创建一个新的子存储库go.sys。

5.在go.sys内部，将有三个独立于syscall的包，分别称为plan9、unix和windows，并且当前syscall包的内容将被适当地分解并安装在这些包中。（这种划分表达了系统之间的基本接口差异，允许一些源代码级别的可移植性，但在包中仍然需要构建标签来分离架构和变体（darwin，linux））。这些是我们希望所有外部Go包在需要支持系统调用时迁移到的包。因为它们是不同的，所以它们更容易管理，更容易使用godoc进行检查，并且可能更容易保持良好的文档记录。这种布局还使如何编写跨平台代码更加清晰：通过将系统相关元素分离为单独导入的组件。

6.go.sys存储库将随着操作系统的发展而更新。

7.标准syscall包的文档将引导用户访问新的存储库。尽管syscall包将继续存在并且可行，但所有新的公共开发都将在go.sys中进行。

8.核心存储库将不依赖于go.sys包，尽管某些子存储库（例如go.net）可能会依赖。

9.与任何标准存储库一样，go.sys存储库将由Go团队管理。将其从主存储库中分离出来使得自动化一些维护变得更加实际可行，例如通过对系统包含文件的详尽处理来自动创建包。

10.自1.3以来在syscall包中发生的任何非必要的提示更改都将迁移到go.sys子存储库。

请注意，由于兼容性保证，我们无法在任何有意义的范围内清理现有的syscall包。但是，我们可以冻结并实际上弃用它。

时间线

我们建议在Go 1.4的2014年9月1日截止日期之前完成这些更改。