| rdfs:comment
| - Kernel markers were a static kernel instrumentation support mechanism for Linux kernel source code, allowing special tools such as LTTng or SystemTap to trace information exposed by these probe points. Kernel markers were declared in the kernel code by one-liners of the form: trace_mark(name, format_string, ...); Where name is the marker's unique name, and format_string describes the remaining arguments' types. A marker can be on or off depending on whether a probe is connected to it or not. Code which wants to hook into a trace point first calls: (en)
- Kernel marker era un mecanismo de soporte de instrumentacón estática para el código fuente del núcleo Linux, permitiendo que las herramientas especiales, tales como LTTng o SystemTap, para rastrear la información expuesta por estos puntos de prueba. Los marcadores de kernel fueron declarados en el código del kernel por una sola línea de código: trace_mark(name, format_string, ...); int marker_probe_register(const char *name, const char *format_string, marker_probe_func *probe, void *pdata); int marker_arm(const char *name);int marker_disarm(const char *name); (es)
|
| has abstract
| - Kernel markers were a static kernel instrumentation support mechanism for Linux kernel source code, allowing special tools such as LTTng or SystemTap to trace information exposed by these probe points. Kernel markers were declared in the kernel code by one-liners of the form: trace_mark(name, format_string, ...); Where name is the marker's unique name, and format_string describes the remaining arguments' types. A marker can be on or off depending on whether a probe is connected to it or not. Code which wants to hook into a trace point first calls: int marker_probe_register(const char *name, const char *format_string, marker_probe_func *probe, void *pdata); to register its probe callback with the marker point (pdata is a private data value that the code wants to pass to the probe). Later, the probe is turned on and off using: int marker_arm(const char *name);int marker_disarm(const char *name); Using markers has a negligible overhead thanks in part to Immediate Values, another support mechanism that embeds switches in the code that can be dynamically turned on and off, without using a memory reference and thus saving cache lines. The initial motivation to create this static instrumentation infrastructure was the large performance overhead induced by the predating dynamic instrumentation mechanism Kprobe mechanism, which depends on breakpoints. Static instrumentation can also more easily survive source code changes because the markers are in the source code. Kernel Markers consisted essentially of a C preprocessing macro which added, in the instrumented function, a branch over a function call. By doing so, neither the stack setup nor the function call are executed when instrumentation is not enabled. By identifying the branch executing stack setup andfunction call as unlikely (using the gcc built-in expect), a hint is given to the compiler to position the tracing instructions away from cache lines involved in standard kernel execution. Two Kernel Markers drawbacks were identified which led to its replacement by Tracepoints:
* Type verification was limited to scalar types because the API is based on format strings. This could be problematic if pointers must be dereferenced by the tracer code.
* The Markers "hide" the instrumentation in the source code, keeping no global registry of the instrumentation. This makes namespace conventions and tracking of instrumentation modification difficult unless the whole kernel tree is monitored. A patch-set implementing them was merged into version 2.6.24, which was released on January 24, 2008. To address issues regarding kernel markers, Mathieu Desnoyers, their original author, implemented a simpler and more type-safe version of static probe points named Tracepoints. A patch-set implementing Tracepoints was merged into version 2.6.28, which was released on December 25, 2008. Starting then, kernel markers were slowly removed from kernel sources and eventually fully removed in Linux kernel 2.6.32, which was released on December 3, 2009. (en)
- Kernel marker era un mecanismo de soporte de instrumentacón estática para el código fuente del núcleo Linux, permitiendo que las herramientas especiales, tales como LTTng o SystemTap, para rastrear la información expuesta por estos puntos de prueba. Los marcadores de kernel fueron declarados en el código del kernel por una sola línea de código: trace_mark(name, format_string, ...); Donde nombre es el nombre único del marcador, y formato_string describe los tipos de argumentos restantes. Un marcador puede estar activado o desactivado dependiendo de si una sonda está conectada a él o no. El código que quiere ver en un primer punto de rastreo de llamadas: int marker_probe_register(const char *name, const char *format_string, marker_probe_func *probe, void *pdata); para registrar su devolución de llamada de la sonda con el punto marcador (pdata es un valor de datos privados que el código quiere pasar a la sonda). Más tarde, la sonda se activa y desactiva usando: int marker_arm(const char *name);int marker_disarm(const char *name); El uso de marcadores tiene una sobrecarga insignificante gracias en parte a los valores inmediatos, otro mecanismo de soporte que incorpora interruptores en el código que se pueden activar y desactivar dinámicamente, sin usar una referencia de memoria y, por lo tanto, guardar las líneas de caché. La motivación inicial para crear esta infraestructura de instrumentación estática fue la gran sobrecarga de rendimiento inducida por el mecanismo de Kprobe, mecanismo de instrumentación dinámica anterior, que depende de los puntos de interrupción. La instrumentación estática también puede sobrevivir más fácilmente a los cambios en el código fuente porque los marcadores están en el código fuente. Los marcadores de kernel consistían esencialmente en una macro de preprocesamiento de C que agregaba, en la función instrumentada, una rama sobre una llamada de función . Al hacerlo, ni la configuración de la pila ni la llamada a la función se ejecutan cuando la instrumentación no está habilitada. Al identificar la configuración de la pila de ejecución de la rama y la llamada a la función como improbable (al usar el gcc incorporado expect), se da una pista al compilador para ubicar las instrucciones de rastreo lejos de las líneas de caché involucradas en la ejecución estándar del kernel. Se identificaron dos inconvenientes de Kernel marker que llevaron a su reemplazo por Tracepoints:
* La verificación de tipo se limitó a tipos escalares porque la API se basa en cadenas de formato. Esto podría ser problemático si los punteros deben ser eliminados por el código trazador.
* Los Marcadores "ocultan" la instrumentación en el código fuente, sin mantener un registro global de la instrumentación. Esto dificulta las convenciones de espacio de nombres y el seguimiento de la modificación de la instrumentación a menos que se supervise todo el árbol del núcleo. Un conjunto de parches implementándolos se fusionó en la versión 2.6.24, que se lanzó el 24 de enero de 2008. Para abordar los problemas relacionados con los marcadores del kernel, Mathieu Desnoyers, su autor original, implementó una versión más simple y más segura de tipos de los puntos de la sonda estática llamados Tracepoints. Un conjunto de parches que implementó Tracepoints se fusionó en la versión 2.6.28, que se lanzó el 25 de diciembre de 2008. A partir de ese momento, los marcadores del kernel se eliminaron lentamente de las fuentes del kernel y finalmente se eliminaron completamente en el núcleo Linux 2.6.32, que fue lanzado el 3 de diciembre de 2009. (es)
|
![[RDF Data]](/fct/images/sw-rdf-blue.png)
![[cxml]](/fct/images/cxml_doc.png)
![[csv]](/fct/images/csv_doc.png)
![[text]](/fct/images/ntriples_doc.png)
![[turtle]](/fct/images/n3turtle_doc.png)
![[ld+json]](/fct/images/jsonld_doc.png)
![[rdf+json]](/fct/images/json_doc.png)
![[rdf+xml]](/fct/images/xml_doc.png)
![[atom+xml]](/fct/images/atom_doc.png)
![[html]](/fct/images/html_doc.png)