Go Binary Hacks - syscallとgolang.org/x/sys/ #golang

はじめに

GoにはOSのシステムコールを実行するためにsyscallパッケージが用意されています。¹

そして同様にシステムコールを実行するための公式外部リポジトリとしてgolang.org/x/sys/リポジトリも存在します。

これら2つのパッケージができた経緯をシステムコールの問題点とともに説明します。

Go syscallパッケージの問題点

1. OSごとに多くのシステムコールや変数定義が存在する。また日々成長を続けている。
2. OSごとに仕様が異なるシステムコールをすべてテストをすることが困難。
3. OSごとに仕様が異なるシステムコールのドキュメントの整備が困難。
4. OSごとのシステムコールの変更要求が多く、取り込むべきかの判断にコストがかかる。
5. Goが変わらずともOS側に変更が入るとGoの互換性を維持することが困難。

Go1.4以降のsyscallパッケージの対応

• syscallパッケージでは、Goの将来のバージョンをサポートするために必要な変更だけが取り込まれます。それ以外の変更はsyscallパッケージには取り込まれません。
• syscallパッケージは、下位バージョンとの互換性を維持する必要があるため、なくなることはありません。
• OS固有の変更は、Goの標準ライブラリからは独立したgolang.org/x/sys/で管理されます。
• パッケージを分割することで、OS固有のドキュメント、テスト、変更の追従ができるようになりました。
• golang.org/x/sys/には、plan9, windows, unixなどOSごとにパッケージが別れており、それぞれ独立して変更が管理されます。
• このパッケージはシステム間の基本的なインターフェースの違いを表現しており、厳密にOSごとに分離されているわけではありません。
• unixパッケージではLinuxとdarwinが対象となっており、ビルドタグによってビルド対象を切り替えます。
• Linuxとdarwinでは完全にシステムコールの仕様が同一ではないので完全な移植性は実現できないはずです。
• Goの標準ライブラリはこのパッケージには依存しません。
• Goチームによって管理されます。

まとめ

このようにシステムコールを使うと移植性は保証されないので、諦めてgolang.org/x/sys/を使うといいでしょう。
とはいいつつ、Goの標準ライブラリから利用しているsyscallパッケージのシステムコールはある程度移植性があるはずなので、利用するシステムコールの機能に応じて使い分けると良いと思います。

参考

• The syscall package

1. システムコールについての詳細な仕組みはGoならわかるシステムプログラミング ― 第5回 Goから見たシステムコールが勉強になります。 ↩