Recommendations needed for tagging kernel addresses.

G.W. Wettstein (
Wed, 28 Jun 1995 11:36:22 CDT

Good day to everyone on the kernel list. Hopefully mid-week will find
things going well for everyone.

We are in the process of re-working the sysklogd package. We have
incorporated a large number of bug fixes and performance enhancements
into the package and it is about time for an updated set of sources.

One of the features that we have been working on is to incorporate on
the fly translation of kernel addresses into the klogd sources. This
was prompted by a discussion on this list a few months ago.

The klogd sources are being modified so that a kernel symbol table can
be read at program start. The kernel output will than be scanned and
any kernel addresses such as the EIP value and the stack trace in a
panic dump or protection fault will be translated into function names.
This is not meant to replace the excellent ksymoops program but rather
is an attempt to increase the quality of kernel bug reports.

The problem that I would like the group to address is how to 'tag'
kernel addresses so as to speed recognition of them. I don't want
klogd to bloat any more than it has to, thus I would like to have some
method of recognizing the addresses which is not parsing intensive.

My inclination is to encapsule the addresses in something like this:


This would be reasonably easy to pick out and hopefully the ugliness
coefficient will be within tolerance.

The second question and one probably best answered by Linus is whether
this should be default format for address output or something which is
selected through a syscall mechanism? Making it the default would
hold the potential for breaking things like ksymoops. Having it
selectable would allow klogd to turn it on only when the kernel log
daemon is running and processing output from the kernel.

Comments and/or suggestions are welcome. Note that I know fully the
limitations of this approach. I know that there is a better than even
chance that klogd will be taken out by the very incident which is
generating the fault messages. It has already been pretty well mashed
out that when a kernel is in its death throes there may not be any
real good method of logging what happened. Hopefully these
enhancements will be useful for random null pointer de-references and
the like.

Have a pleasant remainder of the week.

As always,
Dr. G.W. Wettstein Oncology Research Div. Computing Facility
Roger Maris Cancer Center INTERNET:
820 4th St. N.
Fargo, ND 58122
Phone: 701-234-7556
`The truest mark of a man's wisdom is his ability to listen to other
men expound their wisdom.' -- GWW