I don't see the issue.
Posted Sep 28, 2006 21:38 UTC (Thu) by jd
In reply to: You *can't* require an unchanging interface to changeable internals.
Parent article: Tracing infrastructures
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
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.
to post comments)