Closed yuk1ty closed 3 years ago
『Goなら...』において「libcの関数を叩こう」という趣旨の箇所は(PDF検索が正しければ)なさそうでした。
となると「このリポジトリにおいて、システムコールのラッパーとしてlibcクレートを使うか」については否定派です。 libcの関数はシステムコールのラッパーとしては分厚すぎるため、学習に不向きと考えます。
システムコールのラッパーとして nix クレートを使うのはありだと思います。
生のシステムコールに近いシグネチャで、かつRustっぽい入出力を兼ね備えたものたちが定義されています(write
の例)。
『Goなら...』でもシステムコールを "直接" 叩くことはなく、syscall.Flock()
などの、標準ライブラリに付属している(nix で定義されているような)薄いラッパーを叩いています。
以上をもって、
Go の syscall をどう Rust 向けに変換していくか
に対しては「nix を使う」を私からはおすすめします。 自由にご意見ください。
一方で自分は学習用途として、 (Linux ABI, x86-64 を前提として) アセンブリでシステムコールを呼び出すコード(ある意味でGoの syscall.Foo()
を定義するようなもの)も書いてみたいです。
共通見解としては前のコメントのとおりとして、10.2の別解として nix も libc も使わないやつを提出しようと思います。
Goのsyscall
に対応するのはnix
な気がするのでそこは異論はないのですが、
nix
の実装はlibc
クレートの薄いラッパーなので、libc
が分厚すぎるならnix
はもっと分厚いということになってしまうかと思います。
なので「libc
でもnix
でもいいけど、nix
の方がRust的なsafeインターフェースを提供しているのでnix
にする」という感じかな、と。
あとsyscall
クレートやasm!
で直接書くのは少なくとも原書の内容を超えているので、別解扱いでいいと思います。
おっしゃるとおりですね。
libcの関数はシステムコールのラッパーとしては分厚すぎるため
ここで意図したのは「 fwrite(3)
などのlibcの関数がシステムコールのラッパーとして分厚い」ということでしたが、
libcクレートはシステムコールの薄いラッパーも提供しています( write(2) ラッパーの例)。
libcクレート(のシステムコールのサブセット部分)よりもnixクレートを好むのは
「libcでもnixでもいいけど、nixの方がRust的なsafeインターフェースを提供しているのでnixにする」
という理由です。
了解です。
「システムコールのラッパーでないlibc
の関数を呼ぶ」という部分がないなら、
あまり気にしなくていいのかもしれません。
あとnix
は時々未対応のやつがあるので、もしなかった場合はlibc
になりますね。
9.2.x で goの os.Chmod(), os.Chown() によるファイルのpermission変更の例が出てくるのですが、 nixにありそうなので利用しようと思います。 お勧めあれば教えてください
chmod(2)
の方は標準ライブラリの set_permissions が対応しているみたいですので、こちらを使えば良いと思います。
chown(2)
は自分の検索した限り標準ライブラリにはないので、nixのchown を使えば良さそうです。
基本線は nix
を利用するで行きましょうか。
あとnixは時々未対応のやつがあるので、もしなかった場合はlibcになりますね。
そうですね。私も使っててないやつをいくつか見つけた記憶があります。ラップする関数を作ったら大丈夫だと思います。
「 fwrite(3) などのlibcの関数がシステムコールのラッパーとして分厚い 「libcでもnixでもいいけど、nixの方がRust的なsafeインターフェースを提供しているのでnixにする」
(あまり貢献できていない者からの意見ですみませんが)大変納得感がありました。
節タイトル
ファイルのロック
対象コード
https://github.com/yurakawa/learn-system-programming-with-go/tree/master/ch10/s2-1
補足説明
Go の syscall をどう Rust 向けに変換していくかを現在議論中です。