Kernel markers

Kernel markers

Hi,

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.

Mathieu