Good day to everyone on the list. It is with pleasure that I bring an
on-topic post.... :-)
> Date: Thu, 14 Mar 1996 12:57:53 +1100 (EST)
> From: Keith Owens <kaos@audio.apana.org.au>
>
> Problem with running ksymoops after the event is that the current
> system might not match the modules running when the oops occurred.
> ksymoops would have to read all the way through a log to work out
> which modules were loaded at the oops point, messy.
>
> Agreed.
>
> Suggest that the loaded module data be printed as part of the oops,
> one off data instead of log scanning and interpretation.
>
> Yeah, have some module_map registry linked list of some sort, and if
> module support is enabled oops calls print_module_mappings() or
> something like that. I like this idea.
I have been thinking about this problem for some time. Here are some
thoughts that I have had on the subject.
Those of you who have grabbed the 1.3 version of sysklogd know that
klogd now resolves kernel addresses to their symbolic counterparts.
>From a couple of posts to the list it would seem that a few people are
beginning to use this feature.
When I added this support for klogd I knew that it would be of limited
utility, especially for hard-core kernel hackers. Since the current
solution resides in user-space a really significant kernel event
stands the chance of not being captured. A truely robust solution has
the symbol resolution occurring in the kernel.
I have been toying with the idea of implementing a loadable device
driver to handle this situation. Hopefully we will not be thwarted by
recursion in our efforts... :-)
When I communicated with Linus last fall about adding the [<>]
bracketing to the kernel addresses I briefly mentioned this idea to
him. As everyone knows he is not in favor of a wholesale export of
kernel symbols. His primary objections are based on concerns for the
memory consumptive nature of an in-kernel solution. My feeling was that
he would consider a loadable module implementation.
The loadable module I was considering would have a stub in the
kernel. Whenever the kernel needs to print a potentially resolvable
address a printk_kaddress (or something) would be called. This
function would check a flag to see whether or not the address resolver
module was loaded. If it wasn't the routine would print the numeric
address and return. If the module was loaded the address would be
resolved and its symbolic counterpart printed.
Access to this facility would be through a character device such as
/dev/ksyms or possibly through the writable sysctl facility of the
proc filesystem. Depending on the amount of kernel bloat that would
be tolerated the loading of the symbols could be something as simple
as cat System.map >/dev/ksyms.
My understanding of the implementation of modules and their associated
symbols is still somewhat sketchy. From a brief review of the code it
seems that the kernel maintains a dynamic symbol table which is
updated by module loading and unloading. I envision that it would be
possible for the 'ksyms' device to have hooks into this code so that
addresses from faults occuring in modules could also be resolved.
The last part is pretty fuzzy from my admitted lack of understanding
of the dynamics of loadable kernel modules. I think the idea in
general is a win-win for everyone involved. Those who desire minimal
kernel overhead would only be burdened by the stub functions in the
kernel. Those working on the edge with unstable and/or developmenet
kernels could load the symbol table and have reasonable assurrance of
getting debug information in the event of catastrophic failure. If my
theory on the imbedded kernel symbol table is correct this method
would also positively impact the loadable module problem.
Food for thought. I would be interested in whatever opinions the
group may have. Linus please kick in with a yay/nay if this is
something that is feasible or would be tolerated.
> Later,
> David S. Miller
> davem@caip.rutgers.edu
Greg
}-- End of excerpt from "David S. Miller".
As always,
Dr. G.W. Wettstein Oncology Research Div. Computing Facility
Roger Maris Cancer Center INTERNET: greg@wind.rmcc.com
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