I personally _hate_ using ksymoops. It:
1) doesn't know where /System.map is, so you have to tell it each time.
(it could at least try looking at /System.map and
/boot/System-map-`uname -r` )
2) It doesn't translate multiple oopses, so dmesg | ksymoops /System.map
only translates the first Oops. The others you have to manually
pull out and feed into ksymoops by hand. This is a pain.
3) It is the only c++ program I reguarly compile, so I have to keep all
the c++ stuff around just so I can find out what stupid things I did
this time in my kernel hacking...
So far the argument against using klogd to translate Oops'es has been
simply that klogd could die, so it is necessary to be able to translate
Oopses by hand. Fine. So we keep ksymoops around for the very rare (now
that 2.1.x has such nice exception handling) case where klogd dies. For
everything else, I can see no reason for klogd not trying to translate the
Oops so that newbies don't have to jump through hoops to report problems
intelligently. Even better, this would be one less thing for lazy developers
to have to do. After all, lazyness is the mother of invention...
-Erik
--
Erik B. Andersen Web: http://www.inconnect.com/~andersen/
email: andersee@debian.org
--This message was written using 73% post-consumer electrons--
On Mon, 22 Sep 1997, Richard Gooch wrote:
> H. Peter Anvin writes:
> > > >
> > > > Suggestion: make insmod log the location of each module in the system
> > > > log, or have the kernel output that information ("kernel: loaded
> > > > module foo at 0xe0801130). Then one could use that information from
> > > > the system log to decode the oops, without involving /proc/ksyms.
> > >
> > > It seems people dislike the klogd idea, even if it does everything
> > > that ksymoops is proposing to do. Why? It seems to me (a modified)
> > > klogd has the advantage of not requiring you to do anything to extract
> > > a meaningful log.
> > >
> >
> > For one thing: dmesg often works even when syslogd/klogd doesn't, and
> > I want to be able to decode my dmesg dumps! Furthermore, even if I
> > have to write my kernel messages down by pencil and paper I want to be
> > able to decode them, later, offline.
>
> Fair enough.
>
> Regards,
>
> Richard....
>