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的包,分别称为plan9unixwindows,并且当前syscall包的内容将被适当地分解并安装在这些包中。(这种划分表达了系统之间的基本接口差异,允许一些源代码级别的可移植性,但在包中仍然需要构建标签来分离架构和变体(darwinlinux))。这些是我们希望所有外部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日截止日期之前完成这些更改。