User: Password:
Subscribe / Log in / New account

Kernel markers

Kernel markers

Posted Aug 16, 2007 15:58 UTC (Thu) by compudj (subscriber, #43335)
Parent article: Kernel markers


Being the developer behind the Linux Kernel Markers, I would like to add some clarifications:

The argument "For example, the rate of change of the kernel code base would make the maintenance of a large set of probe points difficult, especially given that developers working on many parts of the code might not be particularly aware of - or concerned about - those points." should be put in context. Actually, if we think of tracing as being provided not only to Linux users, but also to kernel developers, embedded developers, etc, it makes sense to have an intrumentation set which follows the kernel source as closely as possible.

SystemTap's approach of creating an external tapset that have to be ported to each new kernel is correct for users of distribution kernels, but requires much more effort when trying to adapt the tapsets to a rapidly changing code base.

One of the advantages of putting markers at important locations in the kernel code is that they follow the code flow and use the underlying revision control system of the kernel. Moreover, the developers who are the most likely to know what trace points must be inserted and where are probably the maintainers of a subsystem themself. Therefore, it makes sense for them to be the final deciders on wether or not a trace point belongs to a kernel code path.

Second point, the immediate values optimized versions are currently implemented for i386 and powerpc.

Thanks for this thorough coverage of the state of the markers/immediate values.


(Log in to post comments)

Kernel markers

Posted Aug 16, 2007 16:22 UTC (Thu) by davecb (subscriber, #1574) [Link]

It's interesting to compare these with the mostly-dynamic but
sometimes-static approach used in dtrace: almost any function
can be traced without great effort, but a few built-in
static trace points provide higher-level semantics.

A decent explanation of that was Brian Cantrill's comment

I speculate that developers of particular kernel areas
would be active in creating and maintaining high-level and
correlated trace information, and end users could take
advantage of them, but being able to trace on, for example,
entry to an arbitrary function would be th next-most-used


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds