Weekly edition	Kernel	Security	Distributions	Contact Us	Search
Archives	Calendar	Subscribe	Write for LWN	LWN.net FAQ	Sponsors

You can't require an unchanging interface to changeable internals.

Posted Sep 21, 2006 7:34 UTC (Thu) by xoddam (subscriber, #2322)
Parent article: Tracing infrastructures

> Tracepoints clutter the code itself, and they must continue to
> work into the indefinite future. In a sense, each one can be
> thought of as a little system call which, once placed, cannot
> be changed.

That argument looks absurd to me. A tracing interface is intimately
tied to kernel internals. There is no way it should be considered
part of the "Don't break userspace" contract.

The 'marker' idea looks very sound to me. A config option at
compile time could choose static tracepoints, dynamic tracepoints
or no tracepoints at all. Maintaining a set of tracepoints 'out
of tree', when the tracepoints are plainly inside the kernel,
makes far *less* sense than eg. an out-of-tree device driver.

(Log in to post comments)

You *can't* require an unchanging interface to changeable internals.

Posted Sep 21, 2006 19:56 UTC (Thu) by AJWM (guest, #15888) [Link]

> A config option at
> compile time could choose static tracepoints, dynamic tracepoints
> or no tracepoints at all.

Yes, my thoughts exactly on reading this article. It seems to be something that is crying out for a config option or two.

There's still the argument that it's that much more code to maintain, but any arguments about runtime effects would be decided by whoever does the compile.

You *can't* require an unchanging interface to changeable internals.

Posted Sep 22, 2006 0:57 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link]

the problem is that if it has a significant runtime effect it won't be turned on when you need it (production systems running distro kernels)

this needs to be something that redhat (and others) can leave on all the time so that when there are problems the tools can be used.

if you have to recompile the kernel and reboot your production system into a lower-performing kernel for days to weeks until you can duplicate the problem you just are not going to do so.

however if you can run for days or weeks with normal performance, and then when teh problem kicks in load up the tracer to capture what's going on for a bit before you reboot to get things back up again, you have a tool that can be used.

You *can't* require an unchanging interface to changeable internals.

Posted Sep 28, 2006 21:57 UTC (Thu) by efexis (guest, #26355) [Link]

Can't we learn anything from SMP Alternatives? Ie, stick a couple of NOP's in the code big enough to replace it with a CALL instruction when you want to add a tracepoint there. On 64bit systems I guess the CALL instruction is going to be longer (including the 64bit address), so maybe a JMP $+9 and a few NOP's would be quicker than just the NOP's (I haven't looked into processor instruction timings for a -long time-).

I don't see the issue.

Posted Sep 28, 2006 21:38 UTC (Thu) by jd (guest, #26381) [Link]

We already have vast numbers of wrappered calls to the LSM, so clearly people don't object THAT strenuously to wrappered calls in the code. (In fact, if the static tracing were implemented as a LSM module, you could even use the SAME wrappered calls and not need to add a damn thing that isn't already being maintained anyway.)

For that matter, we've a bazillion wrappered calls to BUG() and Torvalds-knows-what else. I see a far stronger cause for objecting to multiple independently-maintained wrappers to trivial, highly specific operations. It would seem to make much more sense to have a single meta-macro that allowed ANY of the assorted tools (lsm, static probes, kernel debugging info, jelly babies, etc) to use ANY of the points to make decisions, based on their specific requirements and the configuration at the time.

This would put all of the complexity into a single meta-macro (so eliminating almost all maintenance issues) and would provide a far wider range of sampleable points for future updates.

In general, added complexity is a Bad Thing. However, if by adding something, you provide a general, unified solution to N existing problems that previously needed N independent solutions, you have actually reduced complexity, which is a Good Thing.

I would not want LTT to be a mainstream kernel component if it actually added to the complexity of the system, but since I see no reason for complexity to be added and ways in which complexity can be removed, I believe LTT in the mainstream kernel is not only achievable but has the potential to cut a lot of crud out. To me, that would be wonderful.