linux - mac - musicbrainz picard español

DTrace en Ubuntu, ¿cómo hacerlo?

Question

Me gustaría usar DTrace en Ubuntu.

https://github.com/dtrace4linux/linux

Hay uno para Linux arriba, el github.

• Me pregunto si dtrace para Linux es igual con dtrace para otros sistemas operativos (Solaris, FreeBSD, OSX).
• Me gustaría encontrar un tutorial para usar esto (dtraceforlinux).
• Me pregunto si el tutorial para dtrace para solaris a continuación es adecuado para mí.

http://www.oracle.com/technetwork/server-storage/solaris/dtrace-tutorial-142317.html

Gracias de antemano. Journeyer

Answer 1

Como autor de dtrace4linux, déjame responder.

En esencia, dtrace en Linux / MacOS / FreeBSD / Solaris es el mismo, todos estamos basados ​​en el mismo código fuente con los mismos objetivos. Debido a que no existe un mantenedor central, los códigos son efectivamente tenedores, con Solaris considerado el maestro. La principal diferencia en el código fuente es el pegamento para cada plataforma.

DTrace es una combinación de varias cosas:

• controlador del kernel
• comando de espacio de usuario "dtrace"
• mecanismos de función de sonda (por ejemplo, syscall, fbt)
• Lenguaje de escritura

Mira el seguimiento de syscall es bastante sencillo:

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

Esto atrapa cada llamada al sistema abierto, sin importar quién lo ejecutó. Si conoces Unix, sabes que el syscall es aproximadamente:

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

Entonces, arg0 es la cadena "nombre de archivo". Pero aquí es donde las cosas difieren. La función C lib es como la anterior, pero esta corresponde a una llamada al sistema, que es algo así como:

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

Entonces el nombre del archivo no está en arg0, sino en arg1. (Disculpa si lo anterior es incorrecto; creo que open() es el mismo en el núcleo y el espacio de usuario, pero esto no es cierto, por ejemplo, para la familia de funciones stat() ).

Aquí es donde surgen algunos de los problemas de "portabilidad" de DTrace: si utiliza una guía de Solaris para dtrace y trata de ejecutar algunos de los scripts o ejemplos, puede encontrar que no funcionan de la misma manera. En teoría, esto es culpa de Linux (my), y dtrace4linux debe modificarse para ocultarlo.

Eso se aplica a las llamadas de sistema.

Ahora veamos fbt. Fbt es solo el seguimiento de funciones, cualquier función, con cualquier parámetro. Puede rastrear la función de Linux que implementa el syscall open() (se llama sys_open [posiblemente]). Si atrapas esta función:

$ dtrace -n fbt::sys_open:

entonces debes mirar el código fuente del núcleo para ver qué es arg0, arg1, arg2, etc. Y casi con seguridad es diferente a Solaris o MacOS: su detalle de implementación de Linux.

Pero es posible que desee acceder a algún argumento, por ejemplo, para obtener alguna estructura interna de datos del kernel (TCP, controlador de disco, controlador USB, etc.). Solaris proporciona "proveedores" que son formas de acceso de mayor nivel a las estructuras de datos que saber "arg3 es una ''struct foo *''". Sin estos proveedores, las secuencias de comandos serían totalmente dependientes de opsys y no serían portables. A la mayoría de las personas no les importa cómo se ve una estructura "tcp", sino que desean acceder a campos clave como pktin, pktout, rcvbytes, sndbytes.

En resumen, dtrace4linux y Solaris dtrace proporcionan una capa de portabilidad para permitir el acceso a estas características o estructuras, pero ni dtrace4linux ni Solaris intentan realizar un trabajo completo para proporcionar portabilidad a través de las miles de estructuras en cada kernel.

En general, puede tomar scripts de tutoriales de Solaris y usarlos para tratar de entender lo que no funciona, pero tratar de usarlos tal como están frustrará si no sabe qué buscar.

Considero dtrace4linux como "no está mal" y "no es lo suficientemente bueno" para ocultar estas diferencias. (dtrace4linux está a la par con MacOS: si utiliza los tutoriales de Solaris, es posible que algunos no funcionen en Mac o FreeBSD).