dtrace4linuxの作者として、私に答えさせてください。
本質的に、Linux / MacOS / FreeBSD / Solarisのdtraceは同じです。私たちはすべて、同じ目標を持つ同じソースコードに基づいています。中央のメンテナがいないため、コードは事実上フォークであり、Solarisがマスターと見なされます。ソースコードの主な違いは、各プラットフォームの接着剤です。
DTraceは、いくつかの組み合わせです。
- カーネルドライバー
- ユーザースペース「dtrace」コマンド
- プローブ機能メカニズム(例:syscall、fbt)
- スクリプト言語
非常に簡単なsyscallトレースを見てください。
$ dtrace -n syscall::open:
.....
これにより、誰が実行したかに関係なく、開いているすべてのシステムコールがトラップされます。Unixを知っているなら、syscallはおおよそ次のとおりです。
open(char *filename, int flags, [int perms])
したがって、arg0は文字列「filename」です。しかし、これは物事が異なるところです。C lib関数は上記のとおりですが、これはシステムコールにマップされます。これは次のようなものです。
open(int someflags, char *filename, int userflags, int perms)
したがって、ファイル名はarg0ではなくarg1にあります。(上記が間違っている場合はお詫びします-カーネルとユーザースペースでは同じだと思いますopen()
が、これは当てはまりません。たとえば、stat()
関数ファミリーの場合などです)。
ここで、DTraceの「移植性」の問題のいくつかが発生します。Solarisガイドを使用してdtraceを実行し、スクリプトまたは例のいくつかを実行しようとすると、同じように機能しない場合があります。理論的には、これはLinux(my)の障害であり、dtrace4linuxを変更してこれを非表示にする必要があります。
それはすべてシステムコールに当てはまります。
次に、fbtを見てみましょう。Fbtは、任意のパラメーターを使用した関数トレース(任意の関数)です。open()
syscallを実装するLinux関数(sys_open
[おそらく]と呼ばれる)をトレースできます。この関数をトラップする場合:
$ dtrace -n fbt::sys_open:
次に、カーネルのソースコードを調べて、arg0、arg1、arg2などが何であるかを確認する必要があります。そして、ほぼ間違いなく、SolarisやMacOSとは異なります。Linuxの実装の詳細です。
ただし、内部カーネルデータ構造(TCP、ディスクドライバー、USBドライバーなど)を取得するために、いくつかの引数にアクセスしたい場合があります。Solarisは、「arg3は'struct foo *'」であると知るよりも、データ構造にアクセスするためのより高いレベルの方法である「プロバイダー」を提供します。これらのプロバイダーがなければ、スクリプトは完全にopsysに依存し、移植性はありません。ほとんどの人は「tcp」構造がどのように見えるかを気にしませんが、pktin、pktout、rcvbytes、sndbytesなどのキーフィールドへのアクセスを望んでいます。
要約するdtrace4linux
と、Solarisdtrace
はこれらの機能または構造へのアクセスを可能にするポータビリティレイヤーを提供しますが、dtrace4linuxもSolarisも、各カーネルの数千の構造にわたるポータビリティを提供するための完全なジョブを実行しようとはしません。
一般に、solarisチュートリアルスクリプトを使用して、機能しないものを理解しようとすることができますが、何を探すべきかわからない場合は、「そのまま」使用しようとするとイライラします。
私は、dtrace4linuxを「悪くない」、「十分ではない」と考えて、これらの違いを隠しています。(dtrace4linuxはMacOSとほぼ同等です。Solarisチュートリアルを使用する場合、MacまたはFreeBSDでは動作しないものもあります)。