Our team is farther along adapting to this change against 2.6.23-mm1,
and we have run into a complication. It's more of a distribution
issue.
We would prefer to retain systemtap's capability to build
instrumentation for a kernel other than the currently running one.
Such instrumentation can be then copied and run on a distinct machine.
This has meant relying on development data: make install_headers +
Makefiles (as packaged by Fedora/RHEL), and to a lesser extent
separated debugging information.
Markers are attractive partly because they don't require debugging
information, so the data needs to be found in an executable image.
But we prefer not to force the executable image itself to be
installed, for example because /boot is relatively small. So we would
prefer something in between: something small that we can put into the
development package.
If there exists sympathy to this problem, Roland McGrath supposes we
could implement a standardized solution, a file like Module.symvers,
containing the marker names & format strings extracted at build time.
Any opinions?
PS. I wonder why the marker name/format strings are put into a
__markers_strings object section at all, considering that the only
place where that is used again appears to be this code in
kernel/module.c:
markersstringsindex = find_sec(hdr, sechdrs, secstrings,
"__markers_strings");
and the "markersstringsindex" variable is never used.
- FChE
-
