| |||||||||||||
Fun with tracepointsFun with tracepointsPosted Aug 13, 2009 7:52 UTC (Thu) by michaeljt (subscriber, #39183)In reply to: Fun with tracepoints by karim Parent article: Fun with tracepoints
One of the arguments I've heard against adding static trace points is that they become part of the kernel ABI and can no longer be removed if they prove not to be useful. Perhaps a way around this argument would be to initially add tracepoints with a mangled name that depends on the current kernel release? That way, until a given set of tracepoints have proved themselves, any scripts using them would have to be updated with every kernel release in order to keep working. The mangling needn't be very complex (e.g. all tracepoints in 2.6.32 which might be removed at a later time could have "dot32" pre-pended to their names), it just needs to be unpredictable in future kernel releases.
(Log in to post comments)
Fun with tracepoints Posted Aug 13, 2009 9:59 UTC (Thu) by addw (guest, #1771) [Link]
I don't see a problem with making it clear that static trace points are NOT part of the ABI, ie that they may come & go. If you are getting that close to the kernel you have got to expect things to change. But how do people use traces ? Probably to look at particular problems, not as general monitoring.
In practice most people use Distro X, version Y. The release people for this will ensure that trace points don't get removed during the 5/... year lifetime of Y, thus you can install new distro provided kernels without worrying. When you rebuild your machine in 5 years time you redo your traces.
|
|||||||||||||