[ltt-dev] tracepoint layer and marker layer

[Jan Blunck]

On Thu, Sep 18, Mathieu Desnoyers wrote:

> The redirection has been asked by kernel developers for four reasons :
> 
> 1 - Markers make the kernel code ugly by adding a format string
> 2 - Markers do not support all what is needed by in-kernel probes from
> other tracers, which is mainly to export pointers to structures along
> with the complete type so the structure content can be later looked into
> by the probe. Markers can only export "%p" (void *). And type casting is
> a bad idea.

Yes, I'm aware of that.

> 3 - Markers are exported directly to userspace. Kernel developers don't
> want to have to bother about a userspace API when they move around
> kernel code. This is why it makes sense to expose the changes made by
> modifying the kernel code to an in-kernel API only.

Hmm, tracepoints are exposed nearly the same way to userspace. Both
technologies are a kernel API since the kernel-userspace boundary is mostly
the relay channel that the userspace is reading from. I don't think it is a
good idea to introduce tracepoints as a layer of indirections just to keep the
markers "stable". At least for tracing that doesn't make any sense since the
tracers itself are in-kernel anyway.

Although this is a different story for the SystemTap usecase.

> 4 - Maintainability. Tracepoints offer a central repository in
> include/trace/*.h, while markers are declared directly in the kernel C
> files, which makes it very hard to maintain.

Right, but I see this more as a benefit for getting the probes type safe. You
still have to maintain the tracepoint code itself in the subsystems.

> Here is what I could do : I could add an optional parameter to the
> markers that would take the associated tracepoint name and the name of
> the callback we are planning to associate with the tracepoint. I could
> therefore use either a gcc builtin type verification or create a
> static inline unused function in the macro to make sure the function
> type matches the type exported by the tracepoint.
> 
> Then it's simply a matter of making the marker code call into the
> tracepoint registration/unregistration functions whenever the marker is
> enabled. Note that in this case, we can remove the if(unlikely()) branch
> from the marker code because it's already done at the tracepoint level,
> and thus becomes redundant.

Interesting idea. I guess it would be worth doing that. On the other hand, I
wonder if it would be of benefit to merge markers and tracepoints and take the
best from both side. But people have to say good by to the myth that the
result provides a stable userspace API ...

Regards,
	Jan

-- 
Jan Blunck <jblunck at suse.de>