カーネル拡張をApple Notary Serviceにアップロードする

個人的にメンテしているHHKPS2USBDriverというカーネル拡張を、Apple Notary Serviceから証明してもらえることができたので記録に残します。

どんな拡張なのか

古いPS/2接続のHappy Hacking Keyboardは、PS/2をUSBに変換するコンバータを使ってmacOSに接続するとCommandキーを正しく入力することができません。この拡張はコンバータ経由でもCommandキーを扱えるようにキーコードを置き換えます。オリジナル版はNAKANISHI Ichiroさんによって作成されましたが、Yosemite以降はコード署名が必須となり使えなくなっていたので、許可を頂いてメンテと公開を行なっています。

• HHKB Driver for OS X 10.10 or later

Apple Notary Serviceにアップロードする

macOS 10.14.5から、Notary Serviceで署名することが基本的に必須となりました。これはカーネル拡張も例外ではないので、HHKPS2USBDriverも対応が必要となりました。Apple公式のドキュメントには、Notary Serviceで署名するためにはXcodeからアップロードするように書かれていますが、カーネル拡張プロジェクトの成果物はGeneric Xcode Archiveと呼ばれる形式になるようで、この形式ではXcodeに Distribute Appオプションが現れないためアップロードすることができません。

Distribute Appが無い

Generic Xcode Archiveが作成されてしまう原因は、アプリのArchiveでipaが作れなくて焦ったメモによると、

• Build SettingsのSkip InstallがNO
• Build PhasesにHeadersがある

のうち片方でも該当すると対象になるようですが、カーネル拡張の場合は上記のパラメータを設定してもGeneric Xcode Archiveから変わりませんでした。

コマンドラインからアップロードする

Generic Xcode Archiveの場合でも、コマンドラインならApple Notary Serviceにアップロード可能です。公式のドキュメントは以下にありました。

• Notarizing Your App Before Distribution | Apple Developer Documentation
• Customizing the Notarization Workflow | Apple Developer Documentation

ドキュメントを読めば書いていますが、少し悩んだところがあったので今回の手順をまとめておきます。

1. Xcodeでアーカイブを作成して署名する
2. OrganizerからDistribute Contentを押してモーダルを開き、Built Productsでカーネル拡張(以下ではHHKPS2USBDriver.kext)を書き出す
3. ditto -c -k --keepParent HHKPS2USBDriver.kext HHKPS2USBDriver.zipを実行
4. Apple IDサイトにログインしてアプリ用パスワードを生成する
5. xcrun altool --notarize-app --primary-bundle-id org.lufia.driver.HHKPS2USBDriver --username '<user@icloud.com>' --password '<passpass>' --file HHKPS2USBDriver.zipでアップロード
6. 終わるまで待つ(10分程度必要でした)

手順4のアプリ用パスワードは、Using app-specific passwords - Apple Supportに作成手順が書かれていますが、Apple IDにログインして、セキュリティのパスワードを生成を押せばすぐに作成できます。

パスワードを生成の場所

また、最後のxcrun altoolは、公式のドキュメントでは@keychain:AC_PASSWORDのようにKeychainのエントリからパスワードを取得していますが、パスワードを直接指定することもできます。今回はローカル環境で実行したため直接書けば問題ありませんでした。ただし、CI環境など不特定多数がログインする環境ならKeychainを使う方がいいでしょう。

上記の手順を終えると、

2019-06-05 13:57:06.788 altool[10401:14566062] No errors uploading 'HHKPS2USBDriver.zip'. RequestUUID = d4db7a94-02b8-4ce9-821b-c4f49d8ba7e5

のようなテキストが出力され、Apple IDに設定しているメールアドレスへメールが届きます。これでプロセスは終わりです。

参考情報

カーネル拡張ではないですが、前職の同僚もNotary Serviceのエントリを書いていました。

• Visual Studio App CenterでmacOSアプリのNotarizationに対応しようとした - backyard of 伊勢的新常識
• macOSアプリに埋め込む実行バイナリのNotarization/Hardened Runtime対応は署名すればOK - backyard of 伊勢的新常識

また、カーネル拡張を開発する時に調べたリンクや自分で過去に書いた記事などです。

• Driverについて
• OSX: Info.plist Properties for Kernel Extensions
• OS X の Kernel Extension に署名する (フェンリル | デベロッパーズブログ)

Info.plistのOSBundleLibrariesは、ビルドしたカーネル拡張をkextlibsで調べると分かります。

$ kextlibs -xml HHKPS2USBDriver

公式Gitのソースコードレイアウト

Gitのソースコードには、gitコマンドをビルドするためのMakefileが含まれている。Gitコマンドのレイアウトを知らなければ理解の難しいものがいくつかあったので調べた。

Gitコマンドのレイアウト

$PATHに含まれる場所(ほとんどは /usr/bin)にGit関連のコマンドが置かれている。

$ ls -l /usr/bin/git* # コマンド出力は一部加工した
git
git-cvsserver
git-receive-pack
git-shell
git-upload-archive
git-upload-pack

$PATHの他に、Gitが参照するgit-coreというディレクトリがあって、git-coreには$PATHにあるもの全てと、git-addのようにgit-がプリフィックスとして付けられた実行ファイルが入っている。git-coreの場所はgit --exec-pathで調べられる。これらのファイルはGitのサブコマンドとして実行できる。実際のところ、ほとんどのファイルはgitにシンボリックリンクを張ったものだけど、本体に組み込まれない一部のサブコマンドは、実行ファイルがそのまま配置されている。

$ git --exec-path
/Library/Developer/CommandLineTools/usr/libexec/git-core

$ ls -l $(git --exec-path) # コマンド出力は一部加工した
git -> ../../bin/git
git-add -> ../../bin/git
git-add--interactive
git-am -> ../../bin/git
git-annotate -> ../../bin/git
git-apply -> ../../bin/git
git-archive -> ../../bin/git
git-bisect
git-bisect--helper -> ../../bin/git
...

余談だけどgitコマンドは$PATHとgit-coreの2箇所に置かれている。同じものだけど、片方が欠けると動かない。

ソースコードレイアウト

Gitのビルドでは、まずlibgit.a、xdiff/lib.aなどライブラリをビルドして、Gitの組み込みコマンドとそれらライブラリをリンクするという順番で行う*1。

Gitリポジトリ直下にある*.cファイルの一部、例えばdir.cやdiff.cなどはlibgit.aとしてビルドされる。このライブラリは、Git本体や、Git本体から独立した単体のサブコマンドとリンクする。リポジトリ直下にあるそれ以外の*.cファイルは、Git本体のソースコードであったり、単体サブコマンドのソースコードであったりする。例えばhttp-fetch.cはgit fetchの実装だが、これはGit本体とは別の単体コマンドとしてビルドされる。

builtin/以下にはGit本体に組み込むサブコマンドのソースコードが置かれている。ほとんどの組み込みサブコマンドはbuiltin/以下のソースコードと1 : 1で対応している。例えばbuiltin/add.cはgit addコマンドそのものであり、cmd_add(argc, argv, prefix)という関数がエントリポイントとなる。これらのファイルは最終的にGit本体に組み込まれて、git-coreにgit-addとしてシンボリックリンクが作られる。組み込みサブコマンドのシンボリックリンクはどれもGit本体を参照しており、Gitは実行時のファイル名によって、どのサブコマンドを実行するかを決定する。ただし、少数ではあるがbuiltin以下に対応するファイルを持たない組み込みサブコマンドも存在する。例えばgit cherry-pickはbuiltin/にファイルを持たないが、git-cherry-pickという名前のシンボリックリンクは用意される。

残りのディレクトリはそれぞれの目的で用意されている。xdiff/はxdiff/lib.aのソースコード、compat/は各プラットフォームの互換性問題を解消するためのソースコードが格納されている。またDocumentation/には詳細なドキュメントが用意されているので眺めてみると面白いと思う。

Makefileの変数

Makefileでは上で説明したファイルをどう扱っているか。Makefile変数を調べた。

LIB_OBJS

• libgit.aを作るためのファイルリスト

BUILTIN_OBJS

• 組み込みサブコマンドのファイルリスト
• Git本体はこれとgit.cと各種ライブラリで作られる

BUILT_INS

• Git本体の組み込みサブコマンドリスト
• BUILTIN_OBJSと、git cherry-pickなどファイルを持たないもの全て

PROGRAM_OBJS

• Git本体に含まれないサブコマンドのリスト
• git-プリフィックスは省略される

PROGRAMS

• PROGRAM_OBJSにgit-プリフィックスを加えたもの

GITLIBS

• Git本体や単体サブコマンドとリンクするファイル
• libgit.a、xdiff/lib.a、common-main.o

BINDIR_PROGRAMS_NEED_X, BINDIR_PROGRAM_NO_X

• 直接$PATHに置かれる単体コマンド
• Windowsの場合に.exeを付けるかどうかで変数を使い分ける

*1:libgit.aはlibgit2とは全く別のものでGitからリンクするためだけに使う

Acmeをプログラムから操作する

Acmeは、Plan 9のために書かれたテキストエディタです。現在はPlan 9 from User SpaceでUnix環境にも移植されています。

このエディタはプログラムから操作するための機能がいくつか用意されていて、それを使うとキーボードやマウスなどの入力イベントを外部のプログラムが受け取り、加工してエディタに反映するなどといったことができます。標準で用意されているのはメーラーですが、最近Russ CoxがTodoを公開していました。

プログラマ向けの情報はAcmeのマニュアルにあります。

• acme(4)

また、Goから扱うためのパッケージもあります。いろいろ複雑なeventファイルを適切に扱ってくれるので便利です。

• acme

基本

Acmeは水色の領域(tag)と黄色の領域(body)を合わせてwindowとして扱います。Acmeはwindow毎に1つディレクトリを用意していて(以下の実行例では1という名前のディレクトリ)、windowを開くたびに2,3...と増えていきます。プログラムからAcmeを操作する場合は、これらのディレクトリを使って行います。

$ 9p ls acme | mc
1       cons    draw    index   log
acme    consctl editout label   new

$ 9p ls acme/1 | mc
addr    ctl     editout event   tag     xdata
body    data    errors  rdsel   wrsel

開いているファイルの取得

acme/indexファイルにも、現在開いているファイルやディレクトリのリストが記録されています。acmeディレクトリを直接読み込んでも同じことはできますが、ほとんどの場合はこちらを使ったほうが簡単でしょう。

$ 9p read acme/index
          1          35         318           1           0 /Users/lufia/ Del Snarf Get | Look 
          2          39          20           0           1 /Users/lufia/.inputrc Del Snarf | Look 
          4          39          26           1           0 /Users/lufia/lib/ Del Snarf Get | Look 
          5          40         101           0           0 /Users/lufia/lib/npmrc Del Snarf | Look 

1行が1つのwindowを表し、左から順番に固定幅で次のような情報が書かれています。

1. windowのID
2. タグ行の文字数(rune)
3. ファイルの文字数(rune)
4. 開いているファイルがディレクトリかどうか(ディレクトリなら1)
5. 開いているファイルが編集中(未保存)かどうか(編集中なら1)
6. タグ行の内容

テキストの編集

windowディレクトリ(1/など)配下のaddrとdataは、編集しているテキストを読み書きするために使います。

• acme/<id>/addr
• acme/<id>/data
• acme/<id>/xdata

addrにAcmeが扱うアドレスを書くとテキストが選択された状態になります。不要な改行を加えるとエラーになるので気をつけましょう。Acmeは以下のような書式をアドレスとして扱います。

• 2 - 2行目を選択
• 2,4 - 2〜4行目を選択
• /func.*\n/ - funcから改行までを選択
• #0,#2 - ファイルの先頭から2文字選択

範囲選択が成功すると、dataとxdataの内容が範囲で選択された部分に置きかわります。dataをreadすると、範囲選択部分が終わってもテキストが続けば最後まで読んでしまいますが、xdataは範囲の終わりでEOFとなります。同様にwriteすると選択した範囲を新しいテキストで置き換えます。

$ 9p read acme/2/body
1行目
2行目
3行目
$ echo -n '2' | 9p write acme/2/addr
$ 9p read acme/2/data
2行目
3行目
$ echo -n '2' | 9p write acme/2/addr
$ 9p read acme/2/xdata
2行目

ただし、addrを更新しても内部的に選択された状態になるだけで、画面とはリンクしていません。画面を更新する場合はctlを使います。

$ echo -n '#30,#45' | 9p write acme/1/addr
$ echo -n 'dot=addr' | 9p write acme/1/ctl

dot=addrは変わったコマンドですが、dotは画面で選択されている範囲、addrはaddrファイルの内容を表すので、addrファイルの内容で画面の選択範囲を更新する意味になります。画面で選択した範囲をaddrに設定するaddr=dotもあります。

イベントの取得

Acmeのイベントは大きく2種類あります。ひとつはエディタ全体でのイベント、もうひとつはwindow単位で発生するイベントです。

acme/log

logはwindowのID、操作、ファイル名の3つが連続したテキストです。ファイル名は省略される場合もあります。実行例を示します。

$ 9p read acme/log
1 focus /Users/lufia/
2 new     # Newコマンドを2ボタンで実行した場合
2 focus 
3 new /Users/lufia/src/    # 3ボタンでファイルを開いた場合
3 focus /Users/lufia/src/
2 del 
3 focus /Users/lufia/src/
3 del /Users/lufia/src/
1 focus /Users/lufia/

スペースで区切った3つのうち、最初のカラムはAcmeのwindowを表す数字です。2つ目は操作を表すコマンドで、これはいくつかあります。

op	意味
new	新しいwindowを作成した
focus	windowにマウスポインタが移動した
del	windowを削除した
get	ファイルを再読み込みした
put	ファイルを保存した
zerox	windowを複製した

最後のカラムは開いているファイル名またはディレクトリ名です。

acme/<id>/event

eventはwindow単位のイベントが流れてくるファイルです。このファイルをopenしている間は、イベントが流れてくる代わりにAcmeデフォルトの動作は止まります(書き戻すことでデフォルトの動作を起こせる)。

ファイルの内容は1つのイベントが1行になっていて、エディタを操作するたびに1行追加されていきます。eventファイルを開いてからのイベントは読み込みできますが、過去のイベントを読むことはできません。

[origin][type][addr0] [addr1] [flag] [n] [text?]\n

originは何からイベントが発生したかを表す1文字です。

origin	どこからイベントが発生したか
E	bodyまたはtagファイル
F	eventファイルへの書き込みなど
K	キーボード入力によるイベント
M	マウス操作によるイベント

typeは大きく4つですが、tagまたはbodyのどちらで発生したものかを区別します。また、typeによって続きのaddr0とaddr1が意味するものが変わります。

type	意味
D	bodyからaddr0〜addr1の範囲が削除された
d	tagからaddr0〜addr1の範囲が削除された
I	bodyのaddr0〜addr1にtextを挿入した
i	tagのaddr0〜addr1にtextを挿入した
L	bodyでtextを検索(マウスボタン3)
l	tagでtextを検索(マウスボタン3)
X	bodyでtext実行(マウスボタン2)
x	tagでtextを実行(マウスボタン2)

Dまたはdイベントの場合、addr0とaddr1の値は削除前の範囲を指します。そのため、イベント発生後に範囲の内容を読み込んでも、元のテキストは消えてしまっているため取り出せません。また、Iまたはiイベントの場合は、addr0とaddr1はテキストを挿入し終えた後の範囲(新しく増えたテキスト部分)を表します。では2文字以上範囲選択した状態でテキスト入力するとどうなるか、ですが、この場合はDとIのイベントに分割されます。従って、addrとdataファイルを使って以下の操作を行なった場合、

$ echo -n 2 | 9p write acme/12/addr
$ echo hello | 9p write acme/12/data

eventファイルには分割された次のイベントが届きます。

FD6 12 0 0
FI6 12 0 6 hello

イベントの残り要素、flagとtextは複雑なのでacmeのマニュアルを読んでください。textは色々な要因により省略されたりします。

利用例

AcmeのファイルAPIを使った例をいくつか挙げます。

# 4行目から9行目の範囲をaddrに設定
echo -n '4,6' | 9p write acme/<id>/addr

# 選択した範囲(4行目から9行目)を読む
9p read acme/<id>/xdata

# 先頭からのオフセットで範囲選択
echo -n '#34,#54' | 9p write acme/5/addr

# 選択した範囲を更新
echo test | 9p write acme/<id>/data

# addrの内容をwindowに反映(dot)
echo -n 'dot=addr' | 9p write acme/<id>/ctl

# windowで選択した範囲をaddrに設定
echo -n 'addr=dot' | 9p write acme/<id>/ctl

# 変更ありの状態にする
echo -n dirty | 9p write acme/<id>/ctl

# 変更ありフラグを落とす
echo -n clean | 9p write acme/<id>/ctl

Plan 9 ANSI/POSIX環境での環境変数

Plan 9ネイティブのCライブラリはPOSIXに準拠しておらず、独自の習慣がある。例えばfopenやfcloseなどは使わずopenやcloseシステムコールを使う。バッファリングが必要であればBiobufを使いなさいという態度を取る。Goの標準パッケージに名残が残っているので、知っていれば雰囲気は伝わると思う。*1

Plan 9の環境変数は/env以下にファイルとして提供されていて、プロセス毎に異なる内容が扱える*2。これらの変数は配列もサポートしていて、配列の場合は\0で区切られたバイト列として表現される。例えばhome='/usr/lufia'の場合、/env/homeには"/usr/lufia"と保存されていて、path=(. /bin)('.'と'/bin'の配列)の場合/env/pathの内容は".\0/bin"となる。

ANSI/POSIX環境

Plan 9にはネイティブ環境の他に、Unixツールを移植するためだけにANSI/POSIX環境(APE)も用意されている。このライブラリはネイティブとは分けて、ヘッダは/sys/include/ape/に、アーカイブは/386/lib/ape/や/amd64/lib/ape/などアーキテクチャ毎に置かれている。POSIXでは、getenvやputenvで設定した環境変数はenviron配列からも同じ内容が参照できなければならないという制約があり、environ配列は"home=/usr/lufia"のような"name=value"形式の文字列配列と定義されているため、ANSI/POSIX環境では/envを使わずメモリ上の配列を操作する方針をとる。だからgetenvはenviron配列を検索するだけの関数で、putenvはenviron配列を更新するだけの関数として用意されている。*3

他のプロセスへ環境変数を引き渡す時は、単純にexecveの引数にenviron配列を渡すだけで良い。execveは渡されたenviron配列を使って/envを再構築する。APEライブラリを使ったプログラムは、mainを実行する前に/envをenviron配列へ読み込む。こうするとPlan 9ネイティブなプログラムは/envを参照すればよいし、APEライブラリを使って書かれたプログラムでは引き続きenviron配列として参照できるようになる。これらの処理は以下のソースコードに書かれている。

• /sys/src/ape/lib/ap/plan9/_envsetup.c
• /sys/src/ape/lib/ap/plan9/execve.c

ただし、Cの文字列は\0を文字列の終わりと扱ってしまうため、ネイティブ環境で配列となっている環境変数をそのまま扱うと(1つ目の\0で終わってしまって)2つ目以降の要素を扱うことができない。ネイティブ環境の場合は/env以下にファイルがあるため、stat等でファイルサイズを取れば長さが分かるけれども、environ配列はCの文字列になってしまうため、本来の長さを知る手段がない。なので_envsetupは\0を0x1に置き換えていて、execveは/envへ書き戻す前に0x1を\0へ戻す実装となっていた。

そういった理由から、Plan 9のANSI/POSIX環境で、getenvを使って得た文字列の途中に0x1が見つかった場合、その文字列は配列として扱ってあげる必要がある。

バグ

余談だけどANSI/POSIX環境のgetenvはenviron配列の要素を指すポインタを返す。putenvはenviron配列を更新するが、getenvが返したポインタがまだ参照されている可能性があるため、以前の値を変更してはいけない。なので何度もputenvを呼び出ししていると、以前の値で使っていたメモリは消すことも再利用することもできずそのままリークする。setenvも最終的にはputenvと同じなので、同じようにリークする。

Plan 9ネイティブのgetenvはmallocした値を返すので、使い終わったらユーザ側で適切にfreeしなければならない。

*1:他にもdialやtokenizeなど割と多く残っている

*2:正確には、rforkのオプションにRFENVGとRFCENVGがあって、これらを使って環境変数を子プロセスと共有したり分離したりといった操作をすることになる

*3:明らかに動いてなかったので修正した

Goでファイルの存在確認

Goでファイルの存在確認について、インターネットではos.Statの戻り値がエラーかどうかを判定する方法が紹介されていますけれど、os.Statはファイルが存在する場合でもエラーを返すことがあるため、この方法では正しく判定できないケースが存在します。また、複数プロセスが同じファイルにアクセスする場合は、os.Statの直後で、別のプロセスによってファイルが作成されたり削除されたりするかもしれません。正確に存在確認する場合は、存在確認した後に行う処理によっていくつかパターンがありますが、基本は、事前に存在を確認するのではなく、意図しない場合にエラーとなるようなフラグを立てておいて、OSのシステムコールが返したエラーを判定することになります。

Cなどでは、Unix系OSと異なり、Windowsは別の関数とフラグを、Plan 9は別のフラグを使いますが、Go標準パッケージのsyscallはその辺りの違いを吸収してくれているので、以下の内容はそのまま使えます。*1

目的別に紹介

ファイルの存在確認をする目的ごとに、対応方法は異なります。以下ではos.OpenFileを使いますが、Goにおいてはos.Openまたはos.Createは以下の呼び出しと同じなので、同じフラグになるのであればどの関数を使っても構いません。

// os.Open(name)は以下と同じ
os.OpenFile(name, os.O_RDONLY, 0)

// os.Create(name)は以下と同じ
os.OpenFile(name, os.O_RDWR|os.O_CREATE|os.O_TRUNC, 0666)

ファイルが存在すれば読む

例えば設定ファイルがあれば読む場合などです。事前の確認を行わず、ファイルを読み込みフラグで開いて、エラーなら、それを使って原因を調べるといいでしょう。

f, err := os.OpenFile(file, os.O_RDONLY, 0)
if err != nil {
    if os.IsNotExist(err) {
        return nil // ファイルが存在しない
    }
    return err // それ以外のエラー(例えばパーミッションがない)
}
// ファイルが正しく読み込める
return nil

ioutil.ReadFileなどを使う場合も、とりあえず読み込んでみて、エラーなら上と同じように判定すればいいです。

ファイルを作成するが存在した場合は何もしない

ファイルがなければデフォルトの値でファイルを作成する場合などで使います。os.O_CREATEと同時にos.O_EXCLをセットすることで、作成できなかった場合にエラーとなるため、存在していたことを判定したい場合はos.IsExistで確認する必要があります。

f, err := os.OpenFile(file, os.O_WRONLY|os.O_CREATE|os.O_EXCL, 0666)
if err != nil {
    if os.IsExist(err) {
        return nil // ファイルが既に存在していた
    }
    return err // それ以外のエラー(例えばパーミッションがない)
}
// ファイルに書き込み可能
return nil

ファイルが存在すれば読み込むが、なければ新規作成する

ログなどをファイルへ書き込む場合に使うと良さそうです。ファイルの有無によりエラーとなることがないため、エラーの判定は特にありません。

f, err := os.OpenFile(file, os.O_RDWR|os.O_CREATE, 0666)
if err != nil {
    return err // エラー(例えばパーミッションがない)
}
// ファイルを読み書き可能
return nil

ファイルが存在すれば削除して新規作成する

設定ファイルの更新などで使います。実際はファイルを削除するわけではなく、os.O_TRUNCフラグによってファイルの内容を消去しています。

f, err := os.OpenFile(file, os.O_WRONLY|os.O_CREATE|os.O_TRUNC, 0666)
if err != nil {
    return err // エラー(例えばパーミッションがない)
}
// ファイルに書き込み可能
return nil

ioutil.WriteFileはこのフラグと同等です。

ファイルが存在すれば削除する

削除の場合はos.OpenFileの代わりにos.Removeを使いますが、基本はos.OpenFileと同様に、実行してからのエラーを判定します。

err := os.Remove(file)
if err != nil {
    if os.IsNotExist(err) {
        return nil // 存在していないので何もしなくていい
    }
    return err // エラー(例えばパーミッションがない)
}
// ファイルに書き込み可能
return nil

参考情報

• Unix Programming with Perl
• Unix Programming with Perl 2

アトミックなファイル更新

ファイルの書き込みについて補足です。

上記では、ファイルの内容を更新するパターンを紹介しましたが、ファイルの内容を更新途中で電源が落ちたなどの原因によって、中途半端な状態が発生することがあります。これを避けるために、POSIXでは同一ファイルシステムにおいてrenameがアトミックであることを利用して、新しいファイルの内容を別のファイルとして保存して、全て終わったあとで本来のファイル名にリネームする手法が使われます。これを自分で書くのは意外と大変なので、Goならnatefinch/atomicを使えば良いでしょう。

また、最近のOSにはファイルの書き込みバッファが存在するため、バッファを使わない一部の例外を除いて、bufio.Writer.Flushなどでフラッシュしてもファイルには書き込まれていない状態が起こり得ます。これがどういった原理なのかは以下の記事が分かりやすいと思います。

• 全言語で気をつけるべき、ファイル書き込み時のお作法

*1:Windowsはsyscall_windows.go、Plan 9はconst_plan9.go辺り

GitをPlan 9に移植した話

2018年の夏頃から、時間をみつけてはPlan 9にGitを移植していて、概ね動いたので公開する。ソースコードはこの辺りにある。

• https://github.com/0intro/plan9-contrib/pull/6
• https://github.com/0intro/plan9-contrib/pull/7
• https://github.com/madler/zlib/pull/398
• https://github.com/libressl-portable/portable/pull/510
• https://github.com/libexpat/libexpat/pull/242
• https://github.com/curl/curl/pull/3701
• https://github.com/git/git/pull/604

GitへのPull requestが個人的な平成最後のPull requestだった。

なぜ移植するのか

Plan 9コミュニティの努力によって、PythonとMercurialは移植されていたけれど、ここ数年はGitHubでホストされるプロジェクトが多く、Gitが使えないと困るようになってきた。一応、今でもgit-wrapperでソースコードのダウンロードは可能だけれど、これはGitHubからzipをダウンロードすることで擬似的に git コマンドを再現しているだけなので、Pull requestを送りたい場合には使えない。

Plan 9でGitを使うためには、公式の git クライアントを移植する方法と、最初から実装する方法の2つあると思う。今回の移植を始める前は、OpenSSLやLibcurlなど、最低限必要なライブラリも全てPlan 9には移植されていなかったし、公式 git クライアントの大部分はCで実装されているので、どうせなら、もっと安全で実装効率の良い言語を使って、必要な部分だけ実装した方がメンテも楽になると思っていた。このアプローチではdgitというGoで再実装しているプロジェクトが存在していて、cloneやmergeなどの基本的なオペレーションは行えるし、今も比較的活発に開発されている。 また、git/fsはCでPlan 9のファイルサーバとして実装しているもので、Plan 9アプリケーションとしてのアプローチは一番正しい。

だけども、独自に実装をしてしまうと、git のアップデートに追従できなくなるんじゃないかという懸念があった。これがGitではなく、RFCみたいな標準仕様があってアップデートも年単位だったなら、Goなどの新しい言語で実装した方がモチベーションも上がるし面倒がないと思う。だけど、Gitは公式のテストケースはあるものの頻繁にアップデートされていくし、それに対してPlan 9開発者は非常に少ないので、公式のコードから離れることは、長期的にみると追従する労力が大きくなって、どこかで限界がくるんじゃないかと思う。だから最善はPlan 9対応のパッチを公式 git クライアントに取り込んでもらうことで、次点ではForkして本家のアップデートに追従しやすくすることじゃないだろうか。今はGitHubがあってパッチも送りやすくなったので、リジェクトされるかもしれないけれど、そんなことで気負いせずに出してみて損はないと思っている。

現在の状況

現在、Plan 9に移植したGitクライアントは、

• git-add
• git-commit
• git-log
• git-diff
• git-clone
• git-push
• git-fetch

など、よく使うコマンドは動くようになった。本当は git-add -p や git-rebase -i も欲しいけど、こういった一部のサブコマンドはシェルスクリプトやPerlで書かれていて、Plan 9のcontrib indexにあるPerlはとても古いのでおそらく動かない。Perlを移植するのはとても大変なので、コードが小さいのであれば、PerlからGoやPythonに書き換えてもいいかなと思う。

Gitを移植する副産物として、openssl や curl コマンドも移植できたし、それなりに動くpthreadも実装できたのは、大変だったけれども結果的には良かった。

Plan 9のローダは先頭から順にシンボルを解決する

半年に1回は8lのエラーでハマっているので書いておこうと思いました。*1

こないだ curl をコンパイルしている時に、こういう設定を mkfile に入れました。

# リンクするライブラリのリスト
LIB=\
    /$objtype/lib/ape/libcurl.a\
    /$objtype/lib/ape/libz.a\
    /$objtype/lib/ape/libcrypto.a\
    /$objtype/lib/ape/libssl.a\

それぞれシンボルはアーカイブに含まれているはずなのに、この書き方では、

inflate_stream: undefined: inflate

のようなエラーでリンクできません。依存を順番に解決するような並びにする必要があります。

LIB=\
    /$objtype/lib/ape/libcurl.a\
    /$objtype/lib/ape/libssl.a\
    /$objtype/lib/ape/libcrypto.a\
    /$objtype/lib/ape/libz.a\

なんで順番が違うだけでエラーなんだろうと思ったら、GCCのスタティックリンクの順番は大事で理由が書かれていました。

gccはリンクする際に引数の順番にライブラリを読んでいきそこで見つからない関数（どこか他のライブラリにあるはず）を見つけるとそれを「見つからないテーブル」に登録する。ライブラリを読み込む中でこの見つからないテーブルにある関数が見つかるとそれを解決する。問題は再帰的にやってくれないことで発生する。どうやら速度上の問題でそうなっているらしい。

*1:Plan 9のリンカはローダと呼ぶらしいです