DTrace на Ubuntu, как?

Как автор dtrace4linux, позвольте мне ответить.

По сути, dtrace в Linux / MacOS / FreeBSD / Solaris одна и та же - все мы основаны на одном исходном коде с одинаковыми целями. Поскольку нет центрального сопровождающего, коды фактически являются ветвями, а Solaris считается ведущим. Основное отличие исходного кода - это связующее звено для каждой платформы.

DTrace - это комбинация нескольких вещей:

• драйвер ядра
• команда пользовательского пространства "dtrace"
• механизмы функции зонда (например, syscall, fbt)
• язык сценариев

Посмотрите, как трассировка системных вызовов довольно проста:

$ dtrace -n syscall::open:
.....

Это перехватывает каждый открытый системный вызов, независимо от того, кто его выполнил. Если вы знакомы с Unix, вы знаете, что системный вызов примерно такой:

open(char *filename, int flags, [int perms])

Итак, arg0 - это строка «имя файла». Но здесь все по-другому. Функция C lib такая же, как указано выше, но она отображается на системный вызов, который выглядит примерно так:

open(int someflags, char *filename, int userflags, int perms)

Таким образом, имя файла находится не в arg0, а в arg1. (Приносим извинения, если приведенное выше неверно - я думаю, что open() одинаково в ядре и в пространстве пользователя, но это неверно, например, для семейства функций stat()).

Именно здесь возникают некоторые из проблем «переносимости» DTrace - если вы воспользуетесь руководством Solaris по dtrace и попытаетесь запустить некоторые сценарии или примеры, вы можете обнаружить, что они не работают одинаково. Теоретически это вина Linux (моя), и dtrace4linux следует изменить, чтобы скрыть это.

Все это относится к системным вызовам.

Теперь посмотрим на fbt. Fbt - это просто трассировка функции - любой функции - с любыми параметрами. Вы можете отследить функцию linux, которая реализует системный вызов open() (он называется 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 и Solaris dtrace предоставляют уровень переносимости, позволяющий получить доступ к этим функциям или структурам, но ни dtrace4linux, ни Solaris не пытаются выполнить полную работу по обеспечению переносимости между тысячами структур в каждом ядре.

В общем, вы можете взять учебные сценарии Solaris и использовать их, чтобы попытаться понять, что не работает, но попытка использовать их «как есть» разочарует вас, если вы не знаете, что искать.

Я считаю dtrace4linux «неплохим» и «недостаточно хорошим», чтобы скрыть эти различия. (dtrace4linux примерно соответствует MacOS - если вы используете руководства по Solaris, некоторые из них могут не работать на Mac или FreeBSD).